Stream: Security and Privacy
Topic: Additional Authorizations workflow for SMART
Keith Boone (Apr 19 2018 at 13:57):
John asked me to post here. I hae another use case for user authorization to address override and electronic signature (not necessarily digital signature) use cases. Rather than go into long detail, see http://motorcycleguy.blogspot.com/2018/04/additional-smart-on-fhir-authorizations.html for a detailed description.
John Moehrke (Apr 19 2018 at 14:18):
The question I have about this use-case first starts with understanding the use-case more fully. It is presented purely as a need for secondary confirmation authorization for some individuals submitting data. Where that second level authorization is used to effectively "Do you really mean to submit that data?". What I don't see in the use-case is what the downstream portion of the use-case. Is there expected that 10 years later when that data are looked at, is there a need to have evidence of the secondary authorization step? If so, then Provenance seems to be a critical portion. If Provenance is critical, then the secondary authorization could be included in the first submission with the inclusion of appropriate Provenance in that original submitted Bundle... Not trying to conclude, just trying to get full use-case understood.
Keith Boone (Apr 19 2018 at 14:49):
@John Moehrke Yes, there is clearly a need for that as well in the use case. Provenance is important in this. I didn't specify how that secondary authorization is captured. My first thought was about how an App would obtain that authorization from the user in a way that was consistent with SMART on FHIR application workflows. Having obtained it, the next step would be to determine how to include it within a create/update API call where information in question is used. PUT/POST take a resource, not a bundle, and I would see this as an additional flow that works with existing create/update API so that applications that support additional authorization can succeed where applications that do not, at least can fail gracefully.
Such a graceful failure occurs today in browsers where if you get a 401 response, the browser has a clue what to do to get the authorization. This would be a similar case, the user tried to do something that needed further authorization, and the App could have a clue about how to get it.
In any case, there's clearly a need to flesh this out in much more detail.
Luis Maas (Apr 19 2018 at 15:55):
Coincidentally, we are working on a workflow for this exact problem that leverages the concept of a transactional scope. In short, the RS signals the client that an additional authorization step is required for a particular transaction by returning a 403 error. You can see the full workflow here:
http://appstudio.interopengine.com/transactional-authorization-for-fhir
Any comments or suggestions are welcome!
Grahame Grieve (Apr 19 2018 at 18:46):
I don't feel great about seeing these things as relationships between the RS and AS, actually. Luis' case is presumably something like transactional authentication for pharmacy dispense (usually done with a physical token) ... but that's exactly why I don't feel great about using the AS: there's nothing inherent in the session that expires - it's a business rule on the transaction.
Grahame Grieve (Apr 19 2018 at 18:47):
also, note this, which is more like Keith's case:
Grahame Grieve (Apr 19 2018 at 18:47):
https://chat.fhir.org/#narrow/stream/102-questionnaire/subject/Challenge
Grahame Grieve (Apr 19 2018 at 18:48):
it doesn't deal with 3rd party authorizations (that's something else again).... but perhaps it could be extended to deal with confirming identity.
John Moehrke (Apr 19 2018 at 18:55):
I agree with Grahame, but am willing to understand the use-case. I will note that this kind of flow is built into SAML, but is not built into OAuth. So there might be some thinking of the SAML mechanism.
Last updated: Apr 12 2022 at 19:14 UTC
