Stream: smart
Topic: online access not core?
Jenni Syed (Aug 18 2020 at 15:29):
In the capabilities, it calls out permissions for offline access, patient, and user scopes. However, there's nothing that calls out online access as a core capability. Is this just an accidental miss or is there some other reason it isn't called out on its own?
Josh Mandel (Aug 18 2020 at 17:01):
I think it's just accidental -- though Isaac's PR from last week removed the "core" designation, so I think maybe the question is: why don't we have a permission-online capability in our list? I think we should! Anyone disagree?
Yunwei Wang (Aug 18 2020 at 17:24):
What does permission-online" mean? I though online permission is default.
Josh Mandel (Aug 18 2020 at 17:33):
By default a server might not support any refresh, right
Yunwei Wang (Aug 18 2020 at 17:50):
Does "online" mean the server issues refresh token when end user is online?
Jenni Syed (Aug 18 2020 at 18:20):
Correct, online means they can refresh while the user is online/session is active
Jenni Syed (Aug 18 2020 at 19:21):
If someone doesn't request online_access or offline_access, we assume it's a "one time use" type situation and wouldn't issue a refresh token to the application
Jenni Syed (Aug 18 2020 at 19:22):
EG: "I'm an app that is going to show my own system's data within the EHR, just need to call provider endpoint to get the email address of the person at first sign in and then I'm done" type situation
Isaac Vetter (Aug 19 2020 at 14:58):
I always thought that "online access" presumed a level of shared session management that doesn't actually exist. For example, how does the AS actually know that the user is still actively using the app (aka "online")? Am I misunderstanding the meaning of this capability/scope?
Michele Mottini (Aug 19 2020 at 15:14):
I think it assumes an embedded app, where the authorization server is part of the host system and so knows when the user is no longer active
Isaac Vetter (Aug 19 2020 at 15:46):
thanks, Michele. So appropriate use of "online access" would re-use the expiration of the access_token as a forced time-out/stand-in for single sign-out? E.g. access_token expires a few minutes after launch, and app can refresh it as long as the app's iframe container is still in active use by the original authorizing user? Do many SMART server implementers really have this level of integration between their web app containers (embedded browser controls/iframe managers) and their authorization servers? I struggle to imagine that they do.
Michele Mottini (Aug 19 2020 at 15:53):
That's how I understand it, and I though Epic, Cerner servers did that ... but clearly Epic's does not!
Michele Mottini (Aug 19 2020 at 15:54):
(ours does not as well for what is worth)
Jenni Syed (Aug 19 2020 at 18:57):
We did have to add some session management workarounds for standalone as well. Obviously non-standard since there's not a good standard... :)
Isaac Vetter (Aug 21 2020 at 03:17):
Michele, why aren't you in our argonaut SMART calls?
Michele Mottini (Aug 21 2020 at 13:50):
Discussing the extended scopes?
Isaac Vetter (Aug 26 2020 at 20:32):
yes, this one
Michele Mottini (Aug 26 2020 at 20:38):
I'll just keep repeating 'don't do it' - will get old quickly
Josh Mandel (Aug 26 2020 at 20:38):
:-)
Josh Mandel (Aug 26 2020 at 20:39):
There are other topics too, like token introspection, launch context, client authentication...
Last updated: Apr 12 2022 at 19:14 UTC
