Stream: ihe
Topic: IHE IUA vs SMART-on-FHIR
Michael van der Zel (Dec 15 2020 at 15:46):
Is SMART-on-FHIR compatible with IHE IUA or the other way around? In other words are the authentication steps of SMART-on-FHIR compatible with IHE:IUA ITI-72 and IHE:IUA ITI-71? And is their use of JWT the same?
Vassil Peytchev (Dec 15 2020 at 16:22):
There is some discussion on that in the current version of IUA (in public comment): https://profiles.ihe.net/ITI/IUA/
If it is not clear enough, or if you think there are better approaches, please comment on it.
Josh Mandel (Dec 15 2020 at 16:27):
Thanks for the link -- I hadn't seen this! Re: JWTs, SMART doesn't make any requirements about access token format (though of course we use JWTs for id_tokens, because that's how OpenID Conenct works).
Michael van der Zel (Dec 16 2020 at 09:11):
Thanks.
For example I created an SMART-on-FHIR app that runs with oauth etc in the smarthealthit sandbox and in the Epic AppOrchard. What do I need to do to claim that it is conform IHE:IUA? Is there a checklist of some kind?
Michael van der Zel (Dec 16 2020 at 09:12):
Ow. Sorry. I see now there is a chapter in the link from Vassil. Thanks!
Michael van der Zel (Dec 17 2020 at 13:33):
Question. IUA Issue 13 says that SMART-on-FHIR specifies OAuth 2.1, but on http://www.hl7.org/fhir/smart-app-launch/ it talks about OAith 2.0?
Josh Mandel (Dec 17 2020 at 14:14):
Are some of the IUA authors present here?
John Moehrke (Dec 17 2020 at 14:17):
yes. myself, @Oliver Egger @Massimiliano Masi -- but you might be best to address your concerns to the github repo, issues.
John Moehrke (Dec 17 2020 at 14:18):
https://github.com/IHE/ITI.IUA
Vassil Peytchev (Dec 17 2020 at 14:18):
Issue 13 states that IUA directly references OAuth 2.1. Presumably, part of the issue is that SMART references OAuth 2.0
John Moehrke (Dec 17 2020 at 14:19):
@Joost Reuzel
John Moehrke (Dec 17 2020 at 14:22):
and input from @Isaac Vetter @Luis Maas @Gregorio Canal @Martin Rosner
Joost Reuzel (Dec 22 2020 at 09:45):
Long answer:
Indeed, IUA references OAuth2.1, where SMART (still) references OAuth2.0. However, this was not the biggest concerns around adopting SMART. OAuth2.1 basically is OAuth2.0, but integrated with all best practices like PKCE, the use of code flow over implicit flow, etc.
Summarizing there were three main concerns around SMART, which prevented it to be adopted into IUA from the start:
- The current SMART specification assumes a tight relation between the authorization server and the resource server, sometimes not even distinguishing the two. For example, does the discovery document belong to the authorization server or resource server?. How would the resource server translate the access token into a set of claims? No mechanism is specified, which implies this is a specific dependency between the two. And how does the authorization server know about the launch contexts? There is no API to announce those in a generic way.
- The SMART-scopes are bound to the default FHIR REST operations. In the various IHE profiles other base protocols are (or will be) used as well. Moreover, the SMART-scopes don't include FHIR messaging or support for the operations like the $apply on ActivityDefinition which are used in IHE profiles as well.
- The SMART-scopes include an authorization context (user/patient/system). The user or patient identifier is resolvable at the resource server. Again a dependency between resource and authorization server. It would have been easier if the context was separated from the scopes into a separate set of claims (which is already partly so as the patient or user id are separate claims). This would allow the IHE transactions based on FHIR to refer to the resources and operations only. The contextual filters based on patient, system or user context would then be tackled in a generic separate way. For example, IUA includes a way of describing the user in its organizational context, which can be used in authorization decisions by the resource server. Something similar can be added for a patient context.
SMART works great for the EMR-launch use-cases, like the Epic AppOrchard. However, we found it somewhat limiting for other use-cases. To extend the applicability of SMART I would recommend the following three:
- Introduce token introspection endpoint to allow the resource server to obtain the claims associated with the access token. Optionally the access token can be formatted as JWT to optimize the number of network calls. I noticed that work is ongoing on this topic, which is great in my view.
- Add an API to register (launch) sessions at an authorization server. This would further decouple resource servers from the authorization servers.
- Update the SMART Scopes: Remove the context from the scopes and place that into separate token claims. Add support for FHIR operations and FHIR messaging to the claims. Enhance the context claims (user/patient/system) to include more contextual information like organization identifiers, roles, etc.
Having said all this, suggestions on how the bridge the gap between the two specifications are quite welcome!
Hope this helps,
Joost
Josh Mandel (Jan 04 2021 at 15:29):
Thanks! A couple of these suggestions are things we are adding in SMART v2 -- specifically, place, token introspection, and support for more FHIR interactions in the scope language.
(I'm not sure I follow the suggestion about removing "context" from scopes; SMART key use cases require the ability to differentiate a request for user level versus patient level access. I might be missing something about the suggestion though.)
Last updated: Apr 12 2022 at 19:14 UTC
