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

[John Moehrke]

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
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>
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
> 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/20160901/ced9da8f/attachment.html>