<div dir="ltr"><div>On Thu, Aug 11, 2016 at 2:37 PM, Aaron Seib <span dir="ltr"><<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>></span> wrote:<br></div><snip><br><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Can we guarantee that any AS a consumer might want to point to won’t introduce a security risk just like email does today? <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If so I am with you.</span></p></div></div></blockquote><div><br></div><div>Yes we can. For example, Google does not restrict what clients I allow to connect to my person-level resources via OAuth. There is no need for HEART to introduce a security vs. privacy compromise. UMA has to deal with this issue, not HEART.<br><br></div><div>Adrian <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p><span class=""><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Aaron Seib, CEO<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">@CaptBlueButton <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> (o) <a href="tel:301-540-2311" value="+13015402311" target="_blank">301-540-2311</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(m) <a href="tel:301-326-6843" value="+13013266843" target="_blank">301-326-6843</a><u></u><u></u></span></p><p class="MsoNormal"><a href="http://nate-trust.org" target="_blank"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none"><img src="cid:image001.jpg@01D1F3DD.D4A30330" width="205" border="0" height="48"></span></a><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p></span><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:agropper@gmail.com" target="_blank">agropper@gmail.com</a> [mailto:<a href="mailto:agropper@gmail.com" target="_blank">agropper@gmail.com</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Thursday, August 11, 2016 12:36 PM<br><b>To:</b> Aaron Seib<br><b>Cc:</b> John Moehrke; ddecouteau; Kretz, Jim M. (SAMHSA/CMHS); Gonzales-Webb, Suzanne (Engility); Kathleen Connor; Johnathan Coleman [SRS]; Davis, John M.; HEART List; Mohammad Jafari</span></p><div><div class="h5"><br><b>Subject:</b> Re: [Openid-specs-heart] Openid-specs-heart Digest, Vol 85, Issue 5<u></u><u></u></div></div><p></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><div><div><div><p class="MsoNormal" style="margin-bottom:12.0pt">Aaron - I think you mostly have it. Also, Justin just made the same point. The RS always has the last word regardless what the AS authorizes. However, the RS should not be allowed to make random overrides to what the AS has authorized. The RS should disclose its policies for overriding the AS at the time the AS is registered so that the patient has a chance to walk away and do business with a different RS. <br><br>This is pretty-much current HIPAA Notice of Privacy Practices practice. A patient can ask a service provider for info-related things at patient-enrollment time and the RS does not have to agree in which case the patient can go elsewhere. Once the RS and the patient have agreed on a set of policies, the RS cannot change their policies without updating the agreement with the patient.<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12.0pt">Your 42CFR example is confusing. Adherence to 42CFR is not a choice of the RS. The introduction of a patient-specified AS actually helps the RS because the AS provides authorization to share with a specific Client just the way 42CFR requires. This effectively indemnifies an RS subject to 42 CFR and that's a win-win.<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12.0pt">You need to come up with a different example of a patient-level FHIR resource that an RS might not want to allow authorization by the patient. HIPAA, for example, says the RS does not have to provide patient access over psych notes. That means that the RS could decide that a Client authorized to receive psych notes is actually a stooge of the patient and they would be allowed under HIPAA to (a) not register psych note resources with the AS in the first place, or (b) register all of FHIR with the AS but then decide when a release authorization shows up to override the part that has to do with psych notes. Either way, this policy should be obvious to the patient at the time of enrollment and AS resource registration.<u></u><u></u></p></div><p class="MsoNormal">Adrian<u></u><u></u></p><div><div><div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Thu, Aug 11, 2016 at 12:15 PM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>> wrote:<u></u><u></u></p><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Just trying to parse your second must –</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The RS (</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7f7f7f">such as the EMR</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">) MUST expose all patient-level resource to <span style="background:yellow">AS</span> authorization – even if it decides to override AS authorization in selected cases that are disclosed (to whom? – the consumer telling them which AS to register, right?) at the time RS-AS resource registration.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In plain English are you saying that the consumer should be able to tell the RS that they have an AS they want to be used and if the RS has policies that would over-ride the preferences configured in the AS of the consumer the RS needs to tell the consumer that is the case. So – if I have an AS that I have set up to say I am all right sharing my substance abuse related data and CFR 42 part 2 applies to the RS – and that facility has decided to not allow data that is covered by CFR 42 part 2 – at the time of AS registration to the RS you want the RS to tell the consumer that this is the case.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If the consumer has provided an ROI that references this AS somehow and tells the RS that they should use that when making disclosure decisions I don’t see how the Facility has the authority to ignore the clients wishes but I think that is workable.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The nuance that I am making is that I am saying that the consumer has to explicitly say in the ROI that the AS they want used.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Is that a part of the preconditions we are going down the road with at this point?</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Aaron Seib, CEO</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">@CaptBlueButton </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> (o) <a href="tel:301-540-2311" target="_blank">301-540-2311</a></span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(m) <a href="tel:301-326-6843" target="_blank">301-326-6843</a></span><u></u><u></u></p><p class="MsoNormal"><a href="http://nate-trust.org" target="_blank"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none"><img src="cid:image004.jpg@01D1F3DC.2BF7F480" width="205" border="0" height="48"></span></a><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:agropper@gmail.com" target="_blank">agropper@gmail.com</a> [mailto:<a href="mailto:agropper@gmail.com" target="_blank">agropper@gmail.com</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Thursday, August 11, 2016 11:53 AM<br><b>To:</b> John Moehrke<br><b>Cc:</b> Aaron Seib; ddecouteau; Kretz, Jim M. (SAMHSA/CMHS); Gonzales-Webb, Suzanne (Engility); Kathleen Connor; Johnathan Coleman [SRS]; Davis, John M.; HEART List; Mohammad Jafari</span><u></u><u></u></p><div><div><p class="MsoNormal"><br><b>Subject:</b> Re: [Openid-specs-heart] Openid-specs-heart Digest, Vol 85, Issue 5<u></u><u></u></p></div></div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><div><div><div><div><p class="MsoNormal" style="margin-bottom:12.0pt">I'm ok with using simple static scopes until UMA figures out how to deal with its problem. <u></u><u></u></p></div><p class="MsoNormal">However, two things are absolutely required in order to claim that HEART is patient-centered:<u></u><u></u></p></div><p class="MsoNormal">1 - The RS MUST accept any UMA-standard AS just like they accept a patient's SMTP-standard email domain or telecom carrier.<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12.0pt">2 - The RS MUST expose all patient-level resources to AS authorization even if it decides to override AS authorization in selected cases that are disclosed at the time of RS-AS resource registration.<u></u><u></u></p></div><p class="MsoNormal">Adrian<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">On Thu, Aug 11, 2016 at 10:50 AM, John Moehrke <<a href="mailto:johnmoehrke@gmail.com" target="_blank">johnmoehrke@gmail.com</a>> wrote:<u></u><u></u></p><div><p class="MsoNormal">I certainly recognize this as the pattern that OAuth and UMA wants. And I encourage us to start here. <u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">I will caution the overall community that the complexity in healthcare data often results in an architecture were the results-about-to-be-returned need to be inspected by the Access Control engine so as to filter out items that match the query parameters, but which are forbidden from being returned because of a Privacy policy. This is fundimentally why there is continuous discussion on the HEART threads. Because those in healthcare recognize this fact, and others are advocating for the pattern that can be implemented off-the-shelf. <u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">Recognizing this. I still suggest we go forward using the pattern that is available from OAuth and UMA; using simple static scopes. We can address the healthcare complexity later. Otherwise we will continuously circle around...<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">John<u></u><u></u></p></div></div><div><p class="MsoNormal"><span style="color:#888888"><br clear="all"></span><u></u><u></u></p><div><div><div><p class="MsoNormal"><span style="color:#888888">John Moehrke<br>Principal Engineering Architect: Standards - Interoperability, Privacy, and Security<br>CyberPrivacy – Enabling authorized communications while respecting Privacy<br>M <a href="tel:%2B1%20920-564-2067" target="_blank">+1 920-564-2067</a><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>"Quis custodiet ipsos custodes?" ("Who watches the watchers?")</span><u></u><u></u></p></div></div></div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">On Thu, Aug 11, 2016 at 9:33 AM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>> wrote:<u></u><u></u></p><div><div><p class="MsoNormal">Makes senseto me Professor.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;color:#575757">Aaron Seib</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:10.0pt;color:#575757"> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:10.0pt;color:#575757">The trick to establishing trust is to avoid all tricks. Especially tricks on yourself.</span><u></u><u></u></p></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br><br>-------- Original message --------<br>From: Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>> <br>Date: 8/11/16 9:19 AM (GMT-05:00) <br>To: Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>>, Kathleen Connor <<a href="mailto:kathleen_connor@comcast.net" target="_blank">kathleen_connor@comcast.net</a>>, <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.<wbr>openid.net</a> <br>Cc: ddecouteau <<a href="mailto:duane.decouteau@gmail.com" target="_blank">duane.decouteau@gmail.com</a>>, "'Kretz, Jim M. (SAMHSA/CMHS)'" <<a href="mailto:Jim.Kretz@samhsa.hhs.gov" target="_blank">Jim.Kretz@samhsa.hhs.gov</a>>, "'Gonzales-Webb, Suzanne (Engility)'" <<a href="mailto:Suzanne.Gonzales-Webb@va.gov" target="_blank">Suzanne.Gonzales-Webb@va.gov</a>><wbr>, <a href="mailto:jc@securityrs.com" target="_blank">jc@securityrs.com</a>, "'Davis, John M.'" <<a href="mailto:Mike.Davis@va.gov" target="_blank">Mike.Davis@va.gov</a>>, Mohammad Jafari <<a href="mailto:mjafari@edmondsci.com" target="_blank">mjafari@edmondsci.com</a>> <br>Subject: Re: [Openid-specs-heart] Openid-specs-heart Digest, Vol 85, Issue 5 <u></u><u></u></p><p>The point here is that the AS shouldn't ever need to access the payload to issue the appropriate tokens. Which it doesn't have to, in either the OAuth or UMA models. That's why we say it's always the RS that enforces the security of the token (and whatever other additional systems there may be). The RS already has the data (obviously, by definition), the AS doesn't.<u></u><u></u></p><p> -- Justin<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">On 8/11/2016 9:02 AM, Aaron Seib wrote:<u></u><u></u></p></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal">For what it is worth I have a question regarding Kathleen's assertion that accessing the payload would be privacy leaking. <u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">Would it be the resource owner that accessed the payload in question? Don't they already have the content that went into creating the payload? <u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">Would leakage only be occurring if the AS was seperated from the RS?<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;color:#575757">Aaron Seib</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:10.0pt;color:#575757"> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:10.0pt;color:#575757">The trick to establishing trust is to avoid all tricks. Especially tricks on yourself.</span><u></u><u></u></p></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br><br>-------- Original message --------<br>From: Kathleen Connor <a href="mailto:kathleen_connor@comcast.net" target="_blank"><kathleen_connor@comcast.net></a> <br>Date: 8/10/16 11:27 PM (GMT-05:00) <br>To: <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.<wbr>openid.net</a> <br>Cc: ddecouteau <a href="mailto:duane.decouteau@gmail.com" target="_blank"><duane.decouteau@gmail.com></a>, "'Kretz, Jim M. (SAMHSA/CMHS)'" <a href="mailto:Jim.Kretz@samhsa.hhs.gov" target="_blank"><Jim.Kretz@samhsa.hhs.gov></a>, "'Gonzales-Webb, Suzanne (Engility)'" <a href="mailto:Suzanne.Gonzales-Webb@va.gov" target="_blank"><Suzanne.Gonzales-Webb@va.gov></a><wbr>, <a href="mailto:jc@securityrs.com" target="_blank">jc@securityrs.com</a>, "'Davis, John M.'" <a href="mailto:Mike.Davis@va.gov" target="_blank"><Mike.Davis@va.gov></a>, Mohammad Jafari <a href="mailto:mjafari@edmondsci.com" target="_blank"><mjafari@edmondsci.com></a> <br>Subject: Re: [Openid-specs-heart] Openid-specs-heart Digest, Vol 85, Issue 5 <br><br>Hi<br><br>RE " The scopes are meant to do coarse-grained authorization and not fine<br>grained authorization... So, scopes can help you do first level of coarse<br>grain authorization which will yield you an access token. Once an access<br>token is valid, grab the contextual information from the payload, header,<br>access token etc. Find a policy associated with the contextual object, and<br>then perform fine level authorization based on the policy."<br><br>Different perspective:<br><br>Scopes could be conveyed using FHIR Security Labels, which do support fine<br>grain authorization, and convey the key policy and context information<br>needed without accessing the payload. <br><br>Having to access payload to make authorization decisions is privacy leaking.<br>There's been a lot of work done in this area by VA, ONC, SAMHSA and others<br>already. K<br><br>Kathleen Connor<br>VHA Security Architecture - Framework Engineering<br>(Edmond Scientific Company)<br>HL7 Security and Financial Management Cochair<br>Office - <a href="tel:360%20357%203536" target="_blank">360 357 3536</a> [Primary]<br>Cell - <a href="tel:360%20480%207599" target="_blank">360 480 7599</a> <br><br>-----Original Message-----<br>From: Openid-specs-heart<br>[<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">mailto:openid-specs-heart-<wbr>bounces@lists.openid.net</a>] On Behalf Of<br><a href="mailto:openid-specs-heart-request@lists.openid.net" target="_blank">openid-specs-heart-request@<wbr>lists.openid.net</a><br>Sent: Wednesday, August 10, 2016 11:57 AM<br>To: <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.<wbr>openid.net</a><br>Subject: Openid-specs-heart Digest, Vol 85, Issue 5<br><br>Send Openid-specs-heart mailing list submissions to<br><a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.<wbr>openid.net</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><br>or, via email, send a message with subject or body 'help' to<br><a href="mailto:openid-specs-heart-request@lists.openid.net" target="_blank">openid-specs-heart-request@<wbr>lists.openid.net</a><br><br>You can reach the person managing the list at<br><a href="mailto:openid-specs-heart-owner@lists.openid.net" target="_blank">openid-specs-heart-owner@<wbr>lists.openid.net</a><br><br>When replying, please edit your Subject line so it is more specific than<br>"Re: Contents of Openid-specs-heart digest..."<br><br><br>Today's Topics:<br><br> 1. Re: HEART Scope Design Proposal #1 (Vivek Biswas)<br> 2. Re: HEART Scope Design Proposal #1<br> (Salyards, Kenneth (SAMHSA/OPPI))<br> 3. Re: HEART Scope Design Proposal #1 (Adrian Gropper)<br><br><br>------------------------------<wbr>------------------------------<wbr>----------<br><br>Message: 1<br>Date: Wed, 10 Aug 2016 17:50:18 +0000 (UTC)<br>From: Vivek Biswas <a href="mailto:vivek_biswas@yahoo.com" target="_blank"><vivek_biswas@yahoo.com></a><br>To: Adrian Gropper <a href="mailto:agropper@healthurl.com" target="_blank"><agropper@healthurl.com></a>,<br><a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">"openid-specs-heart@lists.<wbr>openid.net"</a><br><a href="mailto:openid-specs-heart@lists.openid.net" target="_blank"><openid-specs-heart@lists.<wbr>openid.net></a><br>Cc: Josh Mandel <a href="mailto:jmandel@gmail.com" target="_blank"><jmandel@gmail.com></a>, Grahame Grieve<br><a href="mailto:grahame@healthintersections.com.au" target="_blank"><grahame@healthintersections.<wbr>com.au></a><br>Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br>Message-ID:<br><a href="mailto:1612609796.12186354.1470851418456.JavaMail.yahoo@mail.yahoo.com" target="_blank"><1612609796.12186354.<wbr>1470851418456.JavaMail.yahoo@<wbr>mail.yahoo.com></a><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi Adrian,<br>The scopes are meant to do coarse-grained authorization and not fine grained<br>authorization.<br><br>And hence, this one of the reason why scopes are static string.<br>If one want to perform fine grained authorization, then its based on lot of<br>contextual information like you mention, date-range, geo-location, etc....<br>The contextual information can reside in the Request Payload, in database,<br>within the access token (if JWT) etc. All these contextual information<br>associated with the request can be trusted only if the access token is<br>valid.?<br>There can be a policy associated with context which can help us to decide if<br>the request should be authorized or not.<br>So, scopes can help you do first level of coarse grain authorization which<br>will yield you an access token. Once an access token is valid, grab the<br>contextual information from the payload, header, access token etc. Find a<br>policy associated with the contextual object and than perform fine level<br>authorization based on the policy.<br><br>RegardsVivek Biswas, CISSPConsulting Member @Oracle<br><br><br> From: Adrian Gropper <a href="mailto:agropper@healthurl.com" target="_blank"><agropper@healthurl.com></a><br>To: <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">"openid-specs-heart@lists.<wbr>openid.net"</a><br><a href="mailto:openid-specs-heart@lists.openid.net" target="_blank"><openid-specs-heart@lists.<wbr>openid.net></a><br>Cc: Justin Richer <a href="mailto:jricher@mit.edu" target="_blank"><jricher@mit.edu></a>; Vivek Biswas <a href="mailto:vivek_biswas@yahoo.com" target="_blank"><vivek_biswas@yahoo.com></a>;<br>Josh Mandel <a href="mailto:jmandel@gmail.com" target="_blank"><jmandel@gmail.com></a>; Grahame Grieve<br><a href="mailto:grahame@healthintersections.com.au" target="_blank"><grahame@healthintersections.<wbr>com.au></a><br>Sent: Tuesday, August 9, 2016 12:57 PM<br>Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br> <br>There are many reasons why we need to find a way:<br> <br> - I have never seen a release of information form that did not have a<br>date range. Has anyone? If we say HEART can't do that we're calling into<br>question the legitimacy of HEART.<br> - We have a lot of experience with 75-page CCDAs with the current<br>standards. Many patients have huge health records and it is<br>resource-intensive to get 74-pages of information you already had in order<br>to find the change from the last encounter. The cost is not just on the<br>sender but on the recipient as well. This is probably the top complaint of<br>the current interop methods in my medical society.<br> - I don't think the HEART charter set a particular limit on how much of<br>FHIR we would manage. It's not in our charter to treat effective<br>provider-to-provider exchange as out-of-scope. Once we say that HEART will<br>not support the full patient-level feature set of FHIR, where do we draw the<br>line?<br> - UMA is not OAuth. The goals of the two standards are very different.<br>UMA and HEART are patient-centered. If we restrict HEART to a small fraction<br>of the longitudinal health records or patient-centered health rerecords<br>transactions (because most of the traffic stays in the batch or<br>institution-to-institution domain) then where do we host the discussion on a<br>future for patient-centered records?<br> - There is no logical reason for HEART to not support date ranges once<br>FHIR has that capability. In some jurisdictions, this would be seen as<br>reducing patient's right of access and subject to legal challenge. <br><br>I've added Josh and Grahame to this thread. Let's try and find the solution<br>to this problem even if it involves changing UMA, FHIR or both.<br>Adrian<br><br>On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas <a href="mailto:vivek_biswas@yahoo.com" target="_blank"><vivek_biswas@yahoo.com></a><br>wrote:<br><br>I agree with Justin, that scopes are static string vs scope string be<br>parameterized. Most of the OAuth server support static string.?<br>It will get challenging to implement a profile which requires dynamic string<br>which in turn will hamper the adoption of HEART.<br>We are trying to add contextual information into the scope which are not<br>what scopes are intended for.<br>RegardsVivek Biswas, CISSPConsulting member @Oracle?<br>On Aug 9, 2016, at 9:17 AM, Justin Richer <a href="mailto:jricher@mit.edu" target="_blank"><jricher@mit.edu></a> wrote:<br><br><br>A problem I can see with this is that the ?date? field in particular moves<br>this from something that?s expressible as a table of known strings (like in<br>the appendix of the current spec) to something that?s dynamically<br>parameterized with a potentially infinite set of values. This is a problem<br>in practice as many OAuth implementations treat all scopes as static<br>strings, and will do things like limit set set of scopes a client is allowed<br>to ask for based on a set of registered strings. That?s not possible with a<br>field like ?date? anymore, since the value is filled in at runtime. We tried<br>to have parameterized scopes in BB+ (and even implemented it) but it was<br>generally thought to be too complicated, and required special tooling at the<br>authorizations server.<br>If at all possible, I?d like HEART scopes to not require such special<br>processing and support at the AS.<br><br>?? Justin<br><br>On Aug 8, 2016, at 9:08 PM, Adrian Gropper <a href="mailto:agropper@healthurl.com" target="_blank"><agropper@healthurl.com></a> wrote:<br>Scope Design Proposal #1 aims to support a typical ROI authorization.<br><br>The structure of SDP1 is: patient/date/confidentialitycl ass/resource/edit<br><br>The logic is as follows:<br> <br> - /patient because this applies to only one patient at a time. The<br>patient ID is local to the resource server.<br> - /date is defined by FHIR and can be a range. Putting it at the highest<br>level in the hierarchy (if a scope hierarchy is useful) allows for<br>efficiency in clients requesting updates and reduces the cost to the<br>resource server<br> - /confidentialityclass filters for resources at or below the specified<br>value. Resources that do not have a confidentiality class are considered N -<br>Normal. It is up to the resource server to provide jurisdictictionally<br>appropriate policies and user interfaces for setting confidentiality class<br>other than N on particular resources.<br> - /resource is any resource listed in the particular version of the FHIR<br>specification<br> - /edit is "read", "write", "any" operation by the client on the resource<br>A client might request a scope for immunizations for patient 23 as:[<br>"date=le2016-8-8","conclass=N" , "resource=Immunization", "edit=read" ]<br><br>on a resource registered as: [base]/Patient/23/ with a reference to HEART<br>scopes SDP1 that would tell both the AS and anyone else that dereferenced<br>HEART/SDP1 that the RS would process specific scope strings for date,<br>confidentialityclass, resource, and edit as described above.<br><br>The AS would be free to present SDP1 to the RO any way that it chose.<br><br>A resource server like NYP that wanted to offer registration for sensitive<br>data like Mental Health Treatment would register another resource:<br>[base]/Patient/23/ MentalHealthTx with whatever scopes it offered. <br>These additional resources would not be specified by HEART.<br><br>Any particular RS could choose to support Confidentiality Class, additional<br>resources, neither, or both. <br><br>It would be up to the AS to combine HEART SDP1 resources and additional<br>resources and scopes offered by the RS into whatever policy setting<br>experience it wanted.<br>With this scheme, an AS might offer Alice a policy setting for Observation =<br>R - Restricted even on a resource server that did not support<br>confidentiality class. This would cause all client requests for Observations<br>to fail because the RS would be forced to treat unlabeled resources as N and<br>the authorization tokens for observations were R. The RS could:<br>(a) ignore this problem and treat it as an AS bug,<br>(b) implement confidentiality classification, or<br>(c) offer additional resources and scopes so that the AS could tell Alice<br>that Observations did not include those related to mental health in the hope<br>that Alice would set Observation = N and deal with mental health as a<br>separate part of her policy.<br><br>I believe that, to a first approximation, SDP1 would capture the<br>functionality of most sharing use-cases without forcing the RS to do<br>anything more than it is jurisdictionally already required to do. <br>Adrian<br><br><br>-- <br><br>Adrian Gropper MD<br><br>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE:<a href="http://patientprivacyrights" target="_blank">http://<wbr>patientprivacyrights</a>.<br>org/donate-2/_________________<wbr>_____________ _________________<br>Openid-specs-heart mailing list Openid-specs-heart@lists. <a href="http://openid.net" target="_blank">openid.net</a><br><a href="http://lists.openid.net/" target="_blank">http://lists.openid.net/</a> mailman/listinfo/openid-specs- heart<br><br><br><br><br>______________________________ _________________ Openid-specs-heart mailing<br>list Openid-specs-heart@lists. <a href="http://openid.net" target="_blank">openid.net</a> <a href="http://lists.openid.net/" target="_blank">http://lists.openid.net/</a><br>mailman/listinfo/openid-specs- heart<br><br><br><br><br><br>-- <br><br>Adrian Gropper MD<br><br>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE:<a href="http://patientprivacyrights.org/donate-2/" target="_blank">http://<wbr>patientprivacyrights.org/<wbr>donate-2/</a><br><br> <br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:<br><<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160810/2" target="_blank">http://lists.openid.net/<wbr>pipermail/openid-specs-heart/<wbr>attachments/20160810/2</a><br>d199baa/attachment-0001.html><br><br>------------------------------<br><br>Message: 2<br>Date: Wed, 10 Aug 2016 18:49:42 +0000<br>From: "Salyards, Kenneth (SAMHSA/OPPI)"<br><a href="mailto:Kenneth.Salyards@SAMHSA.hhs.gov" target="_blank"><Kenneth.Salyards@SAMHSA.hhs.<wbr>gov></a><br>To: Vivek Biswas <a href="mailto:vivek_biswas@yahoo.com" target="_blank"><vivek_biswas@yahoo.com></a>, Adrian Gropper<br><a href="mailto:agropper@healthurl.com" target="_blank"><agropper@healthurl.com></a>, <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">"openid-specs-heart@lists.<wbr>openid.net"</a><br><a href="mailto:openid-specs-heart@lists.openid.net" target="_blank"><openid-specs-heart@lists.<wbr>openid.net></a><br>Cc: Josh Mandel <a href="mailto:jmandel@gmail.com" target="_blank"><jmandel@gmail.com></a>, Grahame Grieve<br><a href="mailto:grahame@healthintersections.com.au" target="_blank"><grahame@healthintersections.<wbr>com.au></a><br>Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br>Message-ID:<br><br><<a href="mailto:CY1PR09MB09394BE450F53C13200ECF8CA81D0@CY1PR09MB0939.namprd09.prod.outlook" target="_blank">CY1PR09MB09394BE450F53C13200E<wbr>CF8CA81D0@CY1PR09MB0939.<wbr>namprd09.prod.outlook</a>.<br>com><br><br>Content-Type: text/plain; charset="utf-8"<br><br>Fine grained authorization should be dealt with using a patients? consent<br>directive. FHIR DSTU2 supports consent directive as part of the contract<br>resource. In DSTU3, as I understand the consent directive will not be part<br>of contract. This can work seamlessly within the UMA resource server<br>construct. Ken<br><br>From: Openid-specs-heart<br>[<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">mailto:openid-specs-heart-<wbr>bounces@lists.openid.net</a>] On Behalf Of Vivek<br>Biswas<br>Sent: Wednesday, August 10, 2016 1:50 PM<br>To: Adrian Gropper; <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.<wbr>openid.net</a><br>Cc: Josh Mandel; Grahame Grieve<br>Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br><br>Hi Adrian,<br><br>The scopes are meant to do coarse-grained authorization and not fine grained<br>authorization.<br><br>And hence, this one of the reason why scopes are static string.<br><br>If one want to perform fine grained authorization, then its based on lot of<br>contextual information like you mention, date-range, geo-location, etc....<br><br>The contextual information can reside in the Request Payload, in database,<br>within the access token (if JWT) etc. All these contextual information<br>associated with the request can be trusted only if the access token is<br>valid.<br><br>There can be a policy associated with context which can help us to decide if<br>the request should be authorized or not.<br><br>So, scopes can help you do first level of coarse grain authorization which<br>will yield you an access token. Once an access token is valid, grab the<br>contextual information from the payload, header, access token etc. Find a<br>policy associated with the contextual object and than perform fine level<br>authorization based on the policy.<br><br><br>Regards<br>Vivek Biswas, CISSP<br>Consulting Member @Oracle<br><br><br><br>______________________________<wbr>__<br>From: Adrian Gropper <<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a><a href="mailto:agropper@healthurl.com" target="_blank"><<wbr>mailto:agropper@healthurl.com></a><wbr>><br>To:<br>"<a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.<wbr>openid.net</a><<a href="mailto:openid-specs-heart@lists.openid" target="_blank">mailto:openid-<wbr>specs-heart@lists.openid</a>.<br>net>"<br><<a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.<wbr>openid.net</a><<a href="mailto:openid-specs-heart@lists.openid" target="_blank">mailto:openid-<wbr>specs-heart@lists.openid</a>.<br>net>><br>Cc: Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a><a href="mailto:jricher@mit.edu" target="_blank"><mailto:<wbr>jricher@mit.edu></a>>; Vivek Biswas<br><<a href="mailto:vivek_biswas@yahoo.com" target="_blank">vivek_biswas@yahoo.com</a><a href="mailto:vivek_biswas@yahoo.com" target="_blank"><<wbr>mailto:vivek_biswas@yahoo.com></a><wbr>>; Josh Mandel<br><<a href="mailto:jmandel@gmail.com" target="_blank">jmandel@gmail.com</a><a href="mailto:jmandel@gmail.com" target="_blank"><mailto:<wbr>jmandel@gmail.com></a>>; Grahame Grieve<br><<a href="mailto:grahame@healthintersections.com.au" target="_blank">grahame@healthintersections.<wbr>com.au</a><<a href="mailto:grahame@healthintersections.com.a" target="_blank">mailto:grahame@<wbr>healthintersections.com.a</a><br>u>><br>Sent: Tuesday, August 9, 2016 12:57 PM<br>Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br><br>There are many reasons why we need to find a way:<br><br> 1. I have never seen a release of information form that did not have a<br>date range. Has anyone? If we say HEART can't do that we're calling into<br>question the legitimacy of HEART.<br> 2. We have a lot of experience with 75-page CCDAs with the current<br>standards. Many patients have huge health records and it is<br>resource-intensive to get 74-pages of information you already had in order<br>to find the change from the last encounter. The cost is not just on the<br>sender but on the recipient as well. This is probably the top complaint of<br>the current interop methods in my medical society.<br> 3. I don't think the HEART charter set a particular limit on how much of<br>FHIR we would manage. It's not in our charter to treat effective<br>provider-to-provider exchange as out-of-scope. Once we say that HEART will<br>not support the full patient-level feature set of FHIR, where do we draw the<br>line?<br> 4. UMA is not OAuth. The goals of the two standards are very different.<br>UMA and HEART are patient-centered. If we restrict HEART to a small fraction<br>of the longitudinal health records or patient-centered health rerecords<br>transactions (because most of the traffic stays in the batch or<br>institution-to-institution domain) then where do we host the discussion on a<br>future for patient-centered records?<br> 5. There is no logical reason for HEART to not support date ranges once<br>FHIR has that capability. In some jurisdictions, this would be seen as<br>reducing patient's right of access and subject to legal challenge.<br>I've added Josh and Grahame to this thread. Let's try and find the solution<br>to this problem even if it involves changing UMA, FHIR or both.<br>Adrian<br><br>On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas<br><<a href="mailto:vivek_biswas@yahoo.com" target="_blank">vivek_biswas@yahoo.com</a><a href="mailto:vivek_biswas@yahoo.com" target="_blank"><<wbr>mailto:vivek_biswas@yahoo.com></a><wbr>> wrote:<br>I agree with Justin, that scopes are static string vs scope string be<br>parameterized. Most of the OAuth server support static string.<br><br>It will get challenging to implement a profile which requires dynamic string<br>which in turn will hamper the adoption of HEART.<br><br>We are trying to add contextual information into the scope which are not<br>what scopes are intended for.<br><br>Regards<br>Vivek Biswas, CISSP<br>Consulting member @Oracle<br><br>On Aug 9, 2016, at 9:17 AM, Justin Richer<br><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a><a href="mailto:jricher@mit.edu" target="_blank"><mailto:<wbr>jricher@mit.edu></a>> wrote:<br>A problem I can see with this is that the ?date? field in particular moves<br>this from something that?s expressible as a table of known strings (like in<br>the appendix of the current spec) to something that?s dynamically<br>parameterized with a potentially infinite set of values. This is a problem<br>in practice as many OAuth implementations treat all scopes as static<br>strings, and will do things like limit set set of scopes a client is allowed<br>to ask for based on a set of registered strings. That?s not possible with a<br>field like ?date? anymore, since the value is filled in at runtime. We tried<br>to have parameterized scopes in BB+ (and even implemented it) but it was<br>generally thought to be too complicated, and required special tooling at the<br>authorizations server.<br><br>If at all possible, I?d like HEART scopes to not require such special<br>processing and support at the AS.<br><br>? Justin<br><br>On Aug 8, 2016, at 9:08 PM, Adrian Gropper<br><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a><a href="mailto:agropper@healthurl.com" target="_blank"><<wbr>mailto:agropper@healthurl.com></a><wbr>> wrote:<br><br>Scope Design Proposal #1 aims to support a typical ROI<br>authorization<<a href="https://dl.dropboxusercontent.com/u/8909568/NYP%20authorizatio" target="_blank">https://dl.<wbr>dropboxusercontent.com/u/<wbr>8909568/NYP%20authorizatio</a><br>n.pdf>.<br>The structure of SDP1 is:<br>patient/date<a href="http://hl7.org/fhir/search.html#date" target="_blank"><http://hl7.org/<wbr>fhir/search.html#date></a>/<wbr>confidentialitycl<br>ass<a href="http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html" target="_blank"><http://hl7-fhir.github.io/<wbr>v3/<wbr>ConfidentialityClassification/<wbr>vs.html></a>/reso<br>urce<a href="http://hl7.org/fhir/resourcelist.html" target="_blank"><http://hl7.org/fhir/<wbr>resourcelist.html></a>/edit<br><br>The logic is as follows:<br><br> * /patient because this applies to only one patient at a time. The<br>patient ID is local to the resource server.<br> * /date<a href="http://hl7.org/fhir/search.html#date" target="_blank"><http://hl7.org/fhir/<wbr>search.html#date></a> is defined by FHIR and can<br>be a range. Putting it at the highest level in the hierarchy (if a scope<br>hierarchy is useful) allows for efficiency in clients requesting updates and<br>reduces the cost to the resource server<br> *<br>/confidentialityclass<<a href="http://hl7-fhir.github.io/v3/ConfidentialityClassifica" target="_blank">http://<wbr>hl7-fhir.github.io/v3/<wbr>ConfidentialityClassifica</a><br>tion/vs.html> filters for resources at or below the specified value.<br>Resources that do not have a confidentiality class are considered N -<br>Normal. It is up to the resource server to provide jurisdictictionally<br>appropriate policies and user interfaces for setting confidentiality class<br>other than N on particular resources.<br> * /resource<a href="http://hl7.org/fhir/resourcelist.html" target="_blank"><http://hl7.org/fhir/<wbr>resourcelist.html></a> is any resource<br>listed in the particular version of the FHIR specification<br> * /edit is "read", "write", "any" operation by the client on the<br>resource<br>A client might request a scope for immunizations for patient 23 as:<br><br>[ "date=le2016-8-8","conclass=N" , "resource=Immunization", "edit=read" ]<br><br>on a resource registered as: [base]/Patient/23/ with a reference to HEART<br>scopes SDP1 that would tell both the AS and anyone else that dereferenced<br>HEART/SDP1 that the RS would process specific scope strings for date,<br>confidentialityclass, resource, and edit as described above.<br><br>The AS would be free to present SDP1 to the RO any way that it chose.<br><br>A resource server like NYP that wanted to offer registration for sensitive<br>data like Mental Health Treatment would register another resource:<br>[base]/Patient/23/ MentalHealthTx with whatever scopes it offered.<br>These additional resources would not be specified by HEART.<br><br>Any particular RS could choose to support Confidentiality Class, additional<br>resources, neither, or both.<br><br>It would be up to the AS to combine HEART SDP1 resources and additional<br>resources and scopes offered by the RS into whatever policy setting<br>experience it wanted.<br>With this scheme, an AS might offer Alice a policy setting for Observation =<br>R - Restricted even on a resource server that did not support<br>confidentiality class. This would cause all client requests for Observations<br>to fail because the RS would be forced to treat unlabeled resources as N and<br>the authorization tokens for observations were R. The RS could:<br>(a) ignore this problem and treat it as an AS bug,<br>(b) implement confidentiality classification, or<br>(c) offer additional resources and scopes so that the AS could tell Alice<br>that Observations did not include those related to mental health in the hope<br>that Alice would set Observation = N and deal with mental health as a<br>separate part of her policy.<br>I believe that, to a first approximation, SDP1 would capture the<br>functionality of most sharing use-cases without forcing the RS to do<br>anything more than it is jurisdictionally already required to do.<br><br>Adrian<br><br><br><br>--<br><br>Adrian Gropper MD<br><br>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights" target="_blank">http://patientprivacyrights</a>.<br>org/donate-2/<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><http://<wbr>patientprivacyrights.org/<wbr>donate-2/></a><br>______________________________ _________________ Openid-specs-heart mailing<br>list Openid-specs-heart@lists.<br><a href="http://openid.net" target="_blank">openid.net</a><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank"><mailto:Openid-<wbr>specs-heart@lists.openid.net></a><br><a href="http://lists.openid.net/" target="_blank">http://lists.openid.net/</a> mailman/listinfo/openid-specs-<br>heart<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank"><http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart></a><br><br>______________________________ _________________ Openid-specs-heart mailing<br>list Openid-specs-heart@lists.<br><a href="http://openid.net" target="_blank">openid.net</a><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank"><mailto:Openid-<wbr>specs-heart@lists.openid.net></a><br><a href="http://lists.openid.net/" target="_blank">http://lists.openid.net/</a> mailman/listinfo/openid-specs-<br>heart<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank"><http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart></a><br><br><br><br>--<br><br>Adrian Gropper MD<br><br>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank">http://patientprivacyrights.<wbr>org/donate-2/</a><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:<br><<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160810/3" target="_blank">http://lists.openid.net/<wbr>pipermail/openid-specs-heart/<wbr>attachments/20160810/3</a><br>8084e5a/attachment-0001.html><br><br>------------------------------<br><br>Message: 3<br>Date: Wed, 10 Aug 2016 14:57:02 -0400<br>From: Adrian Gropper <a href="mailto:agropper@healthurl.com" target="_blank"><agropper@healthurl.com></a><br>To: "Salyards, Kenneth (SAMHSA/OPPI)"<br><a href="mailto:Kenneth.Salyards@samhsa.hhs.gov" target="_blank"><Kenneth.Salyards@samhsa.hhs.<wbr>gov></a><br>Cc: Grahame Grieve <a href="mailto:grahame@healthintersections.com.au" target="_blank"><grahame@healthintersections.<wbr>com.au></a>, Josh Mandel<br><a href="mailto:jmandel@gmail.com" target="_blank"><jmandel@gmail.com></a>, <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">"openid-specs-heart@lists.<wbr>openid.net"</a><br><a href="mailto:openid-specs-heart@lists.openid.net" target="_blank"><openid-specs-heart@lists.<wbr>openid.net></a><br>Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br>Message-ID:<br><a href="mailto:CANYRo8goY-qq=iM+KFNP2=YKNzp9c_RH8Ld5ceLLs=iFbabRig@mail.gmail.com" target="_blank"><CANYRo8goY-qq=iM+KFNP2=<wbr>YKNzp9c_RH8Ld5ceLLs=iFbabRig@<wbr>mail.gmail.com></a><br>Content-Type: text/plain; charset="utf-8"<br><br>What is a consent directive?<br><br>What is the relationship of whatever it is to FHIR or any other standard<br>data model?<br><br>How does a consent directive interact with OAuth, UMA or OpenID Connect?<br><br>Do you have an example of how a consent directive maps into, replaces, or<br>changes the NYP ROI authorization form?<br><br>Thanks,<br><br>Adrian<br><br><br><br>On Wed, Aug 10, 2016 at 2:49 PM, Salyards, Kenneth (SAMHSA/OPPI) <<br><a href="mailto:Kenneth.Salyards@samhsa.hhs.gov" target="_blank">Kenneth.Salyards@samhsa.hhs.<wbr>gov</a>> wrote:<br><br>> Fine grained authorization should be dealt with using a patients? <br>> consent directive. FHIR DSTU2 supports consent directive as part of <br>> the contract resource. In DSTU3, as I understand the consent directive <br>> will not be part of contract. This can work seamlessly within the UMA <br>> resource server construct. Ken<br>><br>><br>><br>> *From:* Openid-specs-heart [<a href="mailto:openid-specs-heart" target="_blank">mailto:openid-specs-heart</a>- <br>> <a href="mailto:bounces@lists.openid.net" target="_blank">bounces@lists.openid.net</a>] *On Behalf Of *Vivek Biswas<br>> *Sent:* Wednesday, August 10, 2016 1:50 PM<br>> *To:* Adrian Gropper; <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.<wbr>openid.net</a><br>> *Cc:* Josh Mandel; Grahame Grieve<br>><br>> *Subject:* Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br>><br>><br>><br>> Hi Adrian,<br>><br>><br>><br>> The scopes are meant to do coarse-grained authorization and not fine <br>> grained authorization.<br>><br>><br>><br>> And hence, this one of the reason why scopes are static string.<br>><br>><br>><br>> If one want to perform fine grained authorization, then its based on <br>> lot of contextual information like you mention, date-range, <br>> geo-location, etc....<br>><br>><br>><br>> The contextual information can reside in the Request Payload, in <br>> database, within the access token (if JWT) etc. All these contextual <br>> information associated with the request can be trusted only if the <br>> access token is valid.<br>><br>><br>><br>> There can be a policy associated with context which can help us to <br>> decide if the request should be authorized or not.<br>><br>><br>><br>> So, scopes can help you do first level of coarse grain authorization <br>> which will yield you an access token. Once an access token is valid, <br>> grab the contextual information from the payload, header, access token <br>> etc. Find a policy associated with the contextual object and than <br>> perform fine level authorization based on the policy.<br>><br>><br>><br>><br>><br>> Regards<br>><br>> Vivek Biswas, CISSP<br>><br>> Consulting Member @Oracle<br>><br>><br>><br>><br>><br>><br>> ------------------------------<br>><br>> *From:* Adrian Gropper <a href="mailto:agropper@healthurl.com" target="_blank"><agropper@healthurl.com></a><br>> *To:* <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">"openid-specs-heart@lists.<wbr>openid.net"</a> <<a href="mailto:openid-specs-heart@lists.%0b" target="_blank">openid-specs-heart@lists.<br></a>> <a href="http://openid.net" target="_blank">openid.net</a>><br>> *Cc:* Justin Richer <a href="mailto:jricher@mit.edu" target="_blank"><jricher@mit.edu></a>; Vivek Biswas < <br>> <a href="mailto:vivek_biswas@yahoo.com" target="_blank">vivek_biswas@yahoo.com</a>>; Josh Mandel <a href="mailto:jmandel@gmail.com" target="_blank"><jmandel@gmail.com></a>; Grahame <br>> Grieve < <a href="mailto:grahame@healthintersections.com.au" target="_blank">grahame@healthintersections.<wbr>com.au</a>><br>> *Sent:* Tuesday, August 9, 2016 12:57 PM<br>> *Subject:* Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br>><br>><br>><br>> There are many reasons why we need to find a way:<br>><br>> 1. I have never seen a release of information form that did not have a<br>> date range. Has anyone? If we say HEART can't do that we're calling<br>into<br>> question the legitimacy of HEART.<br>> 2. We have a lot of experience with 75-page CCDAs with the current<br>> standards. Many patients have huge health records and it is<br>> resource-intensive to get 74-pages of information you already had in<br>order<br>> to find the change from the last encounter. The cost is not just on the<br>> sender but on the recipient as well. This is probably the top complaint<br>of<br>> the current interop methods in my medical society.<br>> 3. I don't think the HEART charter set a particular limit on how much<br>> of FHIR we would manage. It's not in our charter to treat effective<br>> provider-to-provider exchange as out-of-scope. Once we say that HEART<br>will<br>> not support the full patient-level feature set of FHIR, where do we<br>draw<br>> the line?<br>> 4. UMA is not OAuth. The goals of the two standards are very<br>> different. UMA and HEART are patient-centered. If we restrict HEART to<br>a<br>> small fraction of the longitudinal health records or patient-centered<br>> health rerecords transactions (because most of the traffic stays in the<br>> batch or institution-to-institution domain) then where do we host the<br>> discussion on a future for patient-centered records?<br>> 5. There is no logical reason for HEART to not support date ranges<br>> once FHIR has that capability. In some jurisdictions, this would be<br>seen as<br>> reducing patient's right of access and subject to legal challenge.<br>><br>> I've added Josh and Grahame to this thread. Let's try and find the <br>> solution to this problem even if it involves changing UMA, FHIR or both.<br>><br>> Adrian<br>><br>><br>><br>> On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas <a href="mailto:vivek_biswas@yahoo.com" target="_blank"><vivek_biswas@yahoo.com></a><br>> wrote:<br>><br>> I agree with Justin, that scopes are static string vs scope string be <br>> parameterized. Most of the OAuth server support static string.<br>><br>><br>><br>> It will get challenging to implement a profile which requires dynamic <br>> string which in turn will hamper the adoption of HEART.<br>><br>><br>><br>> We are trying to add contextual information into the scope which are <br>> not what scopes are intended for.<br>><br>><br>> Regards<br>><br>> Vivek Biswas, CISSP<br>><br>> Consulting member @Oracle<br>><br>><br>> On Aug 9, 2016, at 9:17 AM, Justin Richer <a href="mailto:jricher@mit.edu" target="_blank"><jricher@mit.edu></a> wrote:<br>><br>> A problem I can see with this is that the ?date? field in particular <br>> moves this from something that?s expressible as a table of known <br>> strings (like in the appendix of the current spec) to something that?s <br>> dynamically parameterized with a potentially infinite set of values. <br>> This is a problem in practice as many OAuth implementations treat all <br>> scopes as static strings, and will do things like limit set set of <br>> scopes a client is allowed to ask for based on a set of registered <br>> strings. That?s not possible with a field like ?date? anymore, since <br>> the value is filled in at runtime. We tried to have parameterized <br>> scopes in BB+ (and even implemented<br>> it) but it was generally thought to be too complicated, and required <br>> special tooling at the authorizations server.<br>><br>><br>><br>> If at all possible, I?d like HEART scopes to not require such special <br>> processing and support at the AS.<br>><br>><br>><br>> ? Justin<br>><br>><br>><br>> On Aug 8, 2016, at 9:08 PM, Adrian Gropper <a href="mailto:agropper@healthurl.com" target="_blank"><agropper@healthurl.com></a> wrote:<br>><br>><br>><br>> Scope Design Proposal #1 aims to support a typical ROI authorization <br>> <a href="https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf" target="_blank"><https://dl.<wbr>dropboxusercontent.com/u/<wbr>8909568/NYP%20authorization.<wbr>pdf></a>.<br>><br>> The structure of SDP1 is: patient/date <br>> <a href="http://hl7.org/fhir/search.html#date" target="_blank"><http://hl7.org/fhir/search.<wbr>html#date></a>/confidentialitycl ass <br>> <a href="http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html" target="_blank"><http://hl7-fhir.github.io/v3/<wbr>ConfidentialityClassification/<wbr>vs.html></a>/<br>> resource <a href="http://hl7.org/fhir/resourcelist.html" target="_blank"><http://hl7.org/fhir/<wbr>resourcelist.html></a>/edit<br>><br>><br>> The logic is as follows:<br>><br>> - /patient because this applies to only one patient at a time. The<br>> patient ID is local to the resource server.<br>> - /date <a href="http://hl7.org/fhir/search.html#date" target="_blank"><http://hl7.org/fhir/search.<wbr>html#date></a> is defined by FHIR and<br>> can be a range. Putting it at the highest level in the hierarchy (if a<br>> scope hierarchy is useful) allows for efficiency in clients requesting<br>> updates and reduces the cost to the resource server<br>> - /confidentialityclass<br>> <a href="http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html" target="_blank"><http://hl7-fhir.github.io/v3/<wbr>ConfidentialityClassification/<wbr>vs.html></a><br>> filters for resources at or below the specified value. Resources that<br>do<br>> not have a confidentiality class are considered N - Normal. It is up to<br>the<br>> resource server to provide jurisdictictionally appropriate policies and<br>> user interfaces for setting confidentiality class other than N on<br>> particular resources.<br>> - /resource <a href="http://hl7.org/fhir/resourcelist.html" target="_blank"><http://hl7.org/fhir/<wbr>resourcelist.html></a> is any resource<br>> listed in the particular version of the FHIR specification<br>> - /edit is "read", "write", "any" operation by the client on the<br>> resource<br>><br>> A client might request a scope for immunizations for patient 23 as:<br>><br>> [ "date=le2016-8-8","conclass=N" , "resource=Immunization", <br>> "edit=read" ]<br>><br>> on a resource registered as: [base]/Patient/23/ with a reference to <br>> HEART scopes SDP1 that would tell both the AS and anyone else that <br>> dereferenced HEART/SDP1 that the RS would process specific scope strings<br>for date, confidentialityclass, resource, and edit as described above.<br>><br>> The AS would be free to present SDP1 to the RO any way that it chose.<br>><br>> A resource server like NYP that wanted to offer registration for <br>> sensitive data like Mental Health Treatment would register another<br>resource: [base]/Patient/23/ MentalHealthTx with whatever scopes it offered.<br>> These additional resources would not be specified by HEART.<br>><br>> Any particular RS could choose to support Confidentiality Class,<br>additional resources, neither, or both.<br>><br>> It would be up to the AS to combine HEART SDP1 resources and additional<br>resources and scopes offered by the RS into whatever policy setting<br>experience it wanted.<br>><br>> With this scheme, an AS might offer Alice a policy setting for <br>> Observation = R - Restricted even on a resource server that did not <br>> support confidentiality class. This would cause all client requests <br>> for Observations to fail because the RS would be forced to treat <br>> unlabeled resources as N and the authorization tokens for observations <br>> were R. The RS<br>> could:<br>> (a) ignore this problem and treat it as an AS bug,<br>> (b) implement confidentiality classification, or<br>> (c) offer additional resources and scopes so that the AS could tell <br>> Alice that Observations did not include those related to mental health <br>> in the hope that Alice would set Observation = N and deal with mental <br>> health as a separate part of her policy.<br>><br>> I believe that, to a first approximation, SDP1 would capture the <br>> functionality of most sharing use-cases without forcing the RS to do <br>> anything more than it is jurisdictionally already required to do.<br>><br>> Adrian<br>><br>><br>><br>><br>> --<br>><br>><br>><br>> Adrian Gropper MD<br>><br>> PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>> HELP us fight for the right to control personal health data.<br>> DONATE: <a href="http://patientprivacyrights" target="_blank">http://patientprivacyrights</a>. org/donate-2/ <br>> <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><http://patientprivacyrights.<wbr>org/donate-2/></a><br>><br>> ______________________________ _________________ Openid-specs-heart <br>> mailing list Openid-specs-heart@lists. <a href="http://openid.net" target="_blank">openid.net</a> <br>> <a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank"><Openid-specs-heart@lists.<wbr>openid.net></a><br>> <a href="http://lists.openid.net/" target="_blank">http://lists.openid.net/</a> mailman/listinfo/openid-specs- heart <br>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank"><http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart></a><br>><br>><br>><br>> ______________________________ _________________ Openid-specs-heart <br>> mailing list Openid-specs-heart@lists. <a href="http://openid.net" target="_blank">openid.net</a> <br>> <a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank"><Openid-specs-heart@lists.<wbr>openid.net></a><br>> <a href="http://lists.openid.net/" target="_blank">http://lists.openid.net/</a> mailman/listinfo/openid-specs- heart <br>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank"><http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart></a><br>><br>><br>><br>><br>> --<br>><br>><br>><br>> Adrian Gropper MD<br>><br>> PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>> HELP us fight for the right to control personal health data.<br>> DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank">http://patientprivacyrights.<wbr>org/donate-2/</a><br>><br>><br>><br><br><br><br>-- <br><br>Adrian Gropper MD<br><br>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank">http://patientprivacyrights.<wbr>org/donate-2/</a><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:<br><<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160810/1" target="_blank">http://lists.openid.net/<wbr>pipermail/openid-specs-heart/<wbr>attachments/20160810/1</a><br>d44ada3/attachment.html><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>______________________________<wbr>_________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.<wbr>openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><br><br><br>------------------------------<br><br>End of Openid-specs-heart Digest, Vol 85, Issue 5<br>******************************<wbr>*******************<br><br>______________________________<wbr>_________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.<wbr>openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><u></u><u></u></p><pre>______________________________<wbr>_________________<u></u><u></u></pre><pre>Openid-specs-heart mailing list<u></u><u></u></pre><pre><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.<wbr>openid.net</a><u></u><u></u></pre><pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><u></u><u></u></pre></blockquote><p class="MsoNormal"> <u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>______________________________<wbr>_________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.<wbr>openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><u></u><u></u></p></div><p class="MsoNormal"> <u></u><u></u></p></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>______________________________<wbr>_________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.<wbr>openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><u></u><u></u></p></div><p class="MsoNormal"><br><br clear="all"><br>-- <u></u><u></u></p><div><div><div><div><div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">Adrian Gropper MD<br><br><span style="font-family:"Arial","sans-serif";color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.<wbr>org/donate-2/</span></a></span> <u></u><u></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div><p class="MsoNormal"><br><br clear="all"><br>-- <u></u><u></u></p><div><div><div><div><div><div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Adrian Gropper MD<br><br><span style="font-family:"Arial","sans-serif";color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.<wbr>org/donate-2/</span></a></span> <u></u><u></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><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><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div></div></div>