[Openid-specs-heart] How should a FHIR Server (RS) handle some interactions with with the HEART OAuth 2.0 scopes

Fri Sep 2 15:04:54 UTC 2016

John,

Thanks for the feedback. I can certainly make comments on the FHIR ballot. A few reactions to your comments:

Based on my reading of FHIR, chained searches are separate from includes and reverse includes, however they both provide ways to leak data.

I realize that in designing the scopes, we will not be able to specify for a Resource Server all of the steps it must go through to authorize access to a set of information. However, as an implementer, it seems like it would be good to find guidance along with the scopes, however they are ultimately designed, about what I need to worry about. Whether they are part of the FHIR spec and pointed to by a HEART spec, or just in HEART doesn’t really matter to me.

Search, for obvious reasons, has many places where information can leak. It would be great to see an enumeration of things to consider.

Does this group want to say anything about FHIR operations?

Are Bundle, List, Group and Composition resources that receive additional guidance?

~Andy

From: John Moehrke <johnmoehrke at gmail.com>
Date: Thursday, September 1, 2016 at 3:16 PM
To: "Gregorowicz, Andrew J." <andrewg at mitre.org>
Cc: "openid-specs-heart at lists.openid.net" <openid-specs-heart at lists.openid.net>
Subject: Re: [Openid-specs-heart] How should a FHIR Server (RS) handle some interactions with with the HEART OAuth 2.0 scopes

Hi Andy,

I am co-chair of the HL7 security wg, and member of the FHIR core team.

See the Security page on the FHIR specification for some guidance on Authorization
   http://hl7-fhir.github.io/security.html#binding

I am noticing that the following guidance is not as clear as it could be. It is mentioned under chained search  at
  http://hl7-fhir.github.io/security.html#http

 this would be a good CP on the FHIR ballot.

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.
1. Filter out the results that are not authorized. Returning the results that are authorized.
2. Reject the request as being not authorized. Returning no results

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'

Note that a degenerate state is use of (1) where no results are returned...

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke at gmail.com<mailto:JohnMoehrke at gmail.com>
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Thu, Sep 1, 2016 at 11:04 AM, Gregorowicz, Andrew J. <andrewg at mitre.org<mailto:andrewg at mitre.org>> wrote:
Hello HEART,

I work on maintaining a FHIR server (https://github.com/intervention-engine/fhir). 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.

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.

How should the scopes interact with FHIR Search, specifically with _include and _revinclude (http://www.hl7.org/implement/standards/fhir/search.html#revinclude)?

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?

Either case of rejecting the request increases implementation complexity on the FHIR Server side.

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.

Thanks,

~Andy

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: https://github.com/mitre/heart. Feedback is welcome.

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net<mailto:Openid-specs-heart at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-heart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160902/9764a858/attachment.html>