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

Thu Sep 1 19:01:29 UTC 2016

 I would model the scopes as the 'interaction' verb for a given resource.
 And Conditional Verb which is set in the Http Header acts like an Attribute/Claim which the request is passing.

| Interaction | Path | Request |
|  | Verb | Content-Type | Body | Prefer | Conditional |
| read | /[type]/[id] | GET | N/A | N/A | N/A | O: ETag,If-Modified-Since,If-None-Match |

Hence, scope will be equal to 'read' which will gives us coarse grain access to request.
If conditional element is present in the Http Request than ABAC(Attribute Based Access Control) will be activated which will take into consideration extra authorization requirement based on claims present in the request.
Hence, a mix and match of coarse grain/fine grained access will be required to access the resource.
RegardsVivek Biswas, CISSPConsuting Member of Security Staff.Oracle.

      From: "Gregorowicz, Andrew J." <andrewg at mitre.org>
 To: "openid-specs-heart at lists.openid.net" <openid-specs-heart at lists.openid.net> 
 Sent: Thursday, September 1, 2016 9:04 AM
 Subject: [Openid-specs-heart] How should a FHIR Server (RS) handle some interactions with with the HEART OAuth 2.0 scopes

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/61069cf8/attachment.html>