<div dir="ltr">Hi Andy,<div><br></div><div>I am co-chair of the HL7 security wg, and member of the FHIR core team.</div><div><br></div><div>See the Security page on the FHIR specification for some guidance on Authorization</div><div> <a href="http://hl7-fhir.github.io/security.html#binding">http://hl7-fhir.github.io/security.html#binding</a></div><div><br></div><div>I am noticing that the following guidance is not as clear as it could be. It is mentioned under chained search at</div><div> <a href="http://hl7-fhir.github.io/security.html#http">http://hl7-fhir.github.io/security.html#http</a></div><div><br></div><div> this would be a good CP on the FHIR ballot.</div><div><br></div><div>These search parameters are examples of why the OAuth token is a decision, that the Resource Server must enforce that decision. It is up to the Resource Server to determine if the search results are within the scope. If they are not all within the scope, then there are two different things to do. Neither of these can we define is the right solution, the right solution will be based on policy. That is a local policy will tell you which of these behaviors.</div><div>1. Filter out the results that are not authorized. Returning the results that are authorized.</div><div>2. Reject the request as being not authorized. Returning no results</div><div><br></div><div>Within the first option, there is additional policy determination on if you do this silently, with notice, or with specific notice. Silently means that the requester can't tell by the response that they didn't get full details. Notice would be an indication in the response that some results were suppressed because of policy, but no specifics are given as to what or why the suppression happened. This is indicated using the OperationOutcome.issue.code of 'forbidden'</div><div><br></div><div>Note that a degenerate state is use of (1) where no results are returned...</div><div><br></div><div>John</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">John Moehrke<br>Principal Engineering Architect: Standards - Interoperability, Privacy, and Security<br>CyberPrivacy – Enabling authorized communications while respecting Privacy<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/johnmoehrke</a><br><a href="https://healthcaresecprivacy.blogspot.com" target="_blank">https://healthcaresecprivacy.blogspot.com</a><br>"Quis custodiet ipsos custodes?" ("Who watches the watchers?")</div></div></div>
<br><div class="gmail_quote">On Thu, Sep 1, 2016 at 11:04 AM, Gregorowicz, Andrew J. <span dir="ltr"><<a href="mailto:andrewg@mitre.org" target="_blank">andrewg@mitre.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hello HEART,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I work on maintaining a FHIR server (<a href="https://github.com/intervention-engine/fhir" target="_blank">https://github.com/<wbr>intervention-engine/fhir</a>). As part of my work, I have been implementing code that allow the server to conduct HEART profile compliant OAuth 2.0 authorized
interactions as well as authenticate users using HEART profiled OpenID Connect.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Looking through the archives, it appears that there is some discussion on the FHIR OAuth 2.0 scopes. I wanted to share some implementation experience and questions that may help the discussion going forward.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">How should the scopes interact with FHIR Search, specifically with _include and _revinclude (<a href="http://www.hl7.org/implement/standards/fhir/search.html#revinclude" target="_blank">http://www.hl7.org/implement/<wbr>standards/fhir/search.html#<wbr>revinclude</a>)?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Right now, we have implemented simplistic logic, where if a request is made to the server for search on a given resource, say Condition, that search will be performed if the application generating the request
has been given the user/Condition.read or user/Condition.* scope. What should happen if the search request attempts to _include Encounters for the Conditions and the requesting application has not been granted the appropriate Encounter scopes? Should the server
reject the request? Should it perform the search but not perform the _include? <u></u>
<u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Either case of rejecting the request increases implementation complexity on the FHIR Server side.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Also, I saw some discussion in the archive on bulk. I think it makes sense to address this. I could imagine a patient wanting to load a consult note into their FHIR Server. It may be represented as a FHIR
Bundle that contains individual Conditions, MedicationOrders, Observations, etc. Right now, it is unclear to me what the FHIR Server should do with the HEART scopes if someone were to initiate a batch transaction.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">~Andy<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">PS – We have developed a set of go language tools for implementing HEART profiled OpenID Connect relying parties as well as HEART profiled OAuth 2.0 resource servers here:
<a href="https://github.com/mitre/heart" target="_blank">https://github.com/mitre/heart</a><wbr>. Feedback is welcome.<u></u><u></u></span></p>
</div>
</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></div>