Stream: inferno
Topic: offline_access requirement
Jenni Syed (Mar 04 2021 at 16:28):
In Inferno, test for Limited Access, the description states: "This scenario demonstrates the ability to perform a Patient Standalone Launch to a SMART on FHIR confidential client with limited access granted to the app based on user input. The tester is expected to grant the application access to a subset of desired resource types, and to deny requests for “offline_access” refresh tokens."
Jenni Syed (Mar 04 2021 at 16:30):
I know the ONC requirements do require us to show the user/allow the user to enable offline access for an application. It also requires us to provide a management endpoint to revoke it later. However, I didn't believe there was a requirement to remove the scope for offline_access. There are requirements to revoke "resource level" access scopes, but these are different
Jenni Syed (Mar 04 2021 at 16:30):
Which requirement is inferno attempting to test when it requires us to allow the patient to remove the offline_access scope request?
Jenni Syed (Mar 04 2021 at 16:32):
In addition, if the user removes this, would the app be expected to get online access as an alternative or something else (eg: just single use/very short term)?
Jenni Syed (Mar 04 2021 at 16:32):
(in our system, access tokens are only 15 mins or less)
Robert Scanlon (Mar 04 2021 at 19:22):
There is this section in the preamble of the Final Rule (link):
The “permission-offline” “SMART on FHIR Core Capability” includes support for the “offline_access” scope. Importantly, the implementation specification adopted in § 170.215(a)(3) requires that patients have the ability to explicitly enable the “offline_access” scope during authorization. If the “offline_access” scope is not enabled by patients, patients will be required to re-authenticate and re-authorize an application's access to their EHI after the application's access token expires.
Robert Scanlon (Mar 04 2021 at 19:35):
I'm a little confused because it seems like you acknowledge this here:
I know the ONC requirements do require us to show the user/allow the user to enable offline access for an application.
I initially read that statement's "allow the user to enable" as to also imply "allow the user to deny", which is what we are testing, but is that not what you mean?
Robert Scanlon (Mar 04 2021 at 19:51):
We have no expectations for an online_access refresh token to be granted instead -- ONC has no requirements around online_access tokens.
Jenni Syed (Mar 04 2021 at 23:59):
Correct, we definitely describe to the user when the app is requiring offline access so that they realize they're enabling it. And we allow them to revoke later via the required ONC management endpoint. "Enabling" offline access when an app doesn't ask for it seems odd. And they can fully decline the access if needed (giving an app access for 15 minutes only when they wanted offline isn't going to be very functional - at this point the patient is just declining the access).
Robert Scanlon (Mar 05 2021 at 02:29):
"Enabling" offline access when an app doesn't ask for it seems odd.
I agree, that would be odd, because an app that didn't ask for offline_access probably wouldn't know what to do with a refresh token if given one.
But I think the intent is here is to give the user power to deny offline_access for apps that ask at the time of authorization, not to give the user the power to enable offline_access for apps that don't ask. Thus we are interpreting it from a test perspective as "if an app asks for offline access, the user gets the choice whether to enable offline access or not. If they choose to not enable offline access, then the app will get access but only until the access token expires (in your case, 15 minutes), after which point the app will have to be reauthorized"
I think I understand your approach, which is slightly different. Instead of allowing the user to deny just the "offline_access" scope, thus allowing temporary (15 minute) access to their clinical data, you instead inform the user that the app will receive "offline_access" if authorized but give no ability to deny just the "offline_access" scope. The user can choose to not authorize the app at all, or authorize it with offline_access scope. If they choose to authorize the app, the user is free to revoke the refresh token whenever they like -- if they did it in 15 minutes it would have the exact same effect as not being given a refresh token at all.
Is my description of your approach accurate?
Robert Scanlon (Mar 05 2021 at 02:49):
I think this line contradicts your approach unfortunately, since it describes what must happen when patients choose to not enable the offline access scope but allow access otherwise:
If the “offline_access” scope is not enabled by patients, patients will be required to re-authenticate and re-authorize an application's access to their EHI after the application's access token expires.
Jenni Syed (Mar 05 2021 at 14:51):
the description of our approach is accurate.
Jenni Syed (Mar 05 2021 at 14:57):
it seems like not a great workflow to just enable for 15 minutes when apps expect it. @Pascal Pfiffner How would Apple deal with this scenario?
Jenni Syed (Mar 05 2021 at 14:58):
IE: if a patient granted the app access but didn't give the capability to refresh (thus in systems with short lived tokens, access goes away pretty quickly)
Jenni Syed (Mar 05 2021 at 14:59):
Also curious @Michele Mottini how your application would handle this.
Jenni Syed (Mar 05 2021 at 14:59):
We're curious if this was a misunderstanding of the base SMART spec/assumption and if so, how applications are thinking about handling this today if we enabled it to meet ONC guides
Josh Mandel (Mar 05 2021 at 15:17):
it seems like not a great workflow to just enable for 15 minutes when apps expect it.
While it's not optimal, the reason the workflow is degrading is because the patient made a choice not to allow offline access. What is the alternative? If you just deny the app access and redirect back, how will the app know specifically what the problem was? In theory we could define some interoperable way to say the reason for the denial was this specific scope and the app could retry, but we don't have anything like that today (do we?)
In the current workflow, the best practice for apps is to ask for what you need, and be prepared to deal with what you get, degrading gracefully when you can. Wanting longterm access but having the patient decide to only grant 15 minute access is still pretty darn good for a lot of apps
Robert Scanlon (Mar 05 2021 at 15:17):
Disclaimer: not an app developer. But if I was, I would try to provide a degraded experience if provided limited scopes, while presenting some kind of explanation of why they should reauthorize with all the access I need.
Josh Mandel (Mar 05 2021 at 15:18):
Agreed; I think this is a more precise and succinct version of what I was trying to say.
Robert Scanlon (Mar 05 2021 at 15:19):
I was going to write a lot more, but then your comment popped up and figured reiterating your points again wouldn't make much sense ;-)
Robert Scanlon (Mar 05 2021 at 15:22):
I would love to hear from app developers though. I come at this purely from a theoretical perspective.
Jenni Syed (Mar 05 2021 at 15:24):
Yes, and I agree about handling degraded experiences. But for apps that may hand these off to servers they may not have a great option in this use case. Also, we've seen that apps don't handle degraded experiences today :)
Jenni Syed (Mar 05 2021 at 15:25):
Some of that likely comes from issues where current implementations may not have been returning the "scope" param (so that an app could handle it consistently) but I would love to see an app dev's perspective on this
Michele Mottini (Mar 05 2021 at 15:28):
If there is no refresh token - or attempts to use the refresh token fails - our app will mark the connection as 'expired - please login again' - with a button to start the login sequence again
Robert Scanlon (Mar 05 2021 at 15:33):
In your particular case @Michele Mottini, is one time access to data useful, or is persistent access a necessity? I feel like it would depend on what the app is trying to accomplish, and different apps will be trying to accomplish different things, but I'm curious about your specific case.
Michele Mottini (Mar 05 2021 at 15:42):
It is an app to display / manage all the user health data, so persistent access is very very desirable - users won't be happy to keep having to login
Josh Mandel (Mar 05 2021 at 15:47):
But to be clear, even one-time access lets you fetch their whole history, so one-time access to data is definitely useful for you @Michele Mottini. (I totally agree long-term access is more useful by a lot, but we're talking here about the situation where a patient explicitly does not want to grant that -- would you rather get one-time access or get an error from the authz server?)
Michele Mottini (Mar 05 2021 at 15:59):
Yes sure
Pascal Pfiffner (Mar 05 2021 at 16:34):
Same for us, if a token refresh fails we will show "Please log in again". However, currently we always do expect a refresh token to be present because that was one of the initial requirements.
Jenni Syed (Mar 05 2021 at 16:50):
So, this workflow would result in no refresh token based on how inferno (and the ONC language) currently expects it
Robert Scanlon (Mar 05 2021 at 17:59):
Yes. Do you read that language differently? Maybe if I look hard for a loophole based on precisely what is written there, I could argue that it technically allows you to provide a refresh token if the patient denies offline access, as long as that refresh token cannot extend the life of the access token. So you can hand out a refresh token, but you can't use it to refresh a token. Is there any value in that?
Robert Scanlon (Mar 05 2021 at 18:08):
Inferno's ONC certification tests might actually allow that loophole today, given how we constructed tests. It wasn't our intent though.
Ricky Bloomfield (Mar 05 2021 at 18:13):
Hey folks. Just catching up here. Just to be clear, the language referenced above is in a response to a comment, not the rule itself. The comment response says: "Importantly, the implementation specification adopted in § 170.215(a)(3) requires that patients have the ability to explicitly enable the “offline_access” scope during authorization."
§ 170.215(a)(3) is actually just referring to the SMART App Launch Guide, not any specific language from the rule. So this seems like a very specific interpretation of the SMART App Launch guide that may be in error. In other words, I don't see this "requirement" anywhere in the guide: "that patients have the ability to explicitly enable the “offline_access” scope during authorization."
Ricky Bloomfield (Mar 05 2021 at 18:14):
So I don't think the ONC is trying to say that there needs to be a specific change in the authorization flow.
Ricky Bloomfield (Mar 05 2021 at 18:19):
This is the relevant language from the SMART App Launch Guide:
Refresh tokens are issued to enable sessions to last longer than the validity period of an access token. The app can use the expires_in field from the token response (see step 3) to determine when its access token will expire. EHR implementers are also encouraged to consider using the OAuth 2.0 Token Introspection Protocol to provide an introspection endpoint that clients can use to examine the validity and meaning of tokens. An app with “online access” can continue to get new access tokens as long as the end-user remains online. Apps with “offline access” can continue to get new access tokens without the user being interactively engaged for cases where an application should have long-term access extending beyond the time when a user is still interacting with the client.
The app requests a refresh token in its authorization request via the online_access or offline_access scope (see SMART on FHIR Access Scopes for details). A server can decide which client types (public or confidential) are eligible for offline access and able to receive a refresh token. If granted, the EHR supplies a refresh_token in the token response. After an access token expires, the app requests a new access token by providing its refresh token to the EHR’s token endpoint. An HTTP POST transaction is made to the EHR authorization server’s token URL, with content-type application/x-www-form-urlencoded. The decision about how long the refresh token lasts is determined by a mechanism that the server chooses. For clients with online access, the goal is to ensure that the user is still online.
Ricky Bloomfield (Mar 05 2021 at 18:20):
Nothing here about a patient having the ability to "explicitly enable" the scope "during authorization"
Jenni Syed (Mar 05 2021 at 18:41):
That was in line with our original interpretation/we are wondering if this was a misinterpretation of the SMART standard
Robert Scanlon (Mar 05 2021 at 20:01):
Ah, I see that perspective now (took me a little while). Thanks @Jenni Syed and @Ricky Bloomfield. ONC will have to weigh in on this, and we'll have the tests reflect what they say.
Ricky Bloomfield (Mar 05 2021 at 20:21):
Thanks, @Robert Scanlon. I think it's important that we're not adding requirements that aren't explicitly called out in the text of the rule. Wouldn't it be better to remove that requirement from Inferno until ONC explicitly says it should be included (versus the other way around)?
Robert Scanlon (Mar 05 2021 at 20:39):
I agree it is important to only test to ONC's requirements, and we need to fix any incorrect tests as quickly as possible. But this is also an explicit check in the approved test procedure, which we do not want to deviate from.
Robert Scanlon (Mar 05 2021 at 20:44):
The health IT developer demonstrates the ability of Health IT Module to evaluate the authorization request and request end-user input, if applicable (required for patient-facing applications), including the ability for the end-user to explicitly enable the “offline_access” scope according to the implementation specification adopted in § 170.215(a)(3).
Ricky Bloomfield (Mar 05 2021 at 21:00):
Very helpful. Thanks. Yes, I agree we need to clarify with ONC whether they intended to deviate from the SMART App Launch Guide and create a new requirement here.
Jenni Syed (Apr 06 2021 at 22:19):
The ONC released clarification about this today: https://www.healthit.gov/test-method/standardized-api-patient-and-population-services#ccg
Jenni Syed (Apr 06 2021 at 22:20):
The paragraph at § 170.215(a)(3) requires health IT developers to support the SMART Application Launch Framework Implementation Guide (SMART IG) “SMART [on FHIR] Core Capabilities,” including “permission-offline,” which grants support for refresh tokens. The ONC Cures Act Final Rule states, “…Importantly, the implementation specification adopted in § 170.215(a)(3) requires that patients have the ability to explicitly enable the “offline_access” scope during authorization. If the “offline_access” scope is not enabled by patients, patients will be required to re-authenticate and re-authorize an application's access to their EHI after the application's access token expires…” (85 FR 25747). However, the ability of a patient to explicitly enable the “offline_access” scope during authorization is not described in the implementation specification. ONC clarifies that health IT developers must support the ability for patients to be provided information about an application’s request for persistent access prior to the patient sharing their health information, in order to enable patients to make an informed decision during authorization. Examples include, but are not limited to a health IT developer allowing patients to granularly grant “offline-access” scopes during authorization or clearly providing this information as a notice during authorization. The critical requirement is that patients are empowered to deny authorization for offline access.
Jenni Syed (Apr 06 2021 at 22:21):
This seems to be in line with our interpretation: our consent page makes it clear that the application will get offline access and how to manage this later. They can choose to deny access to the app, or grant it, but can't grant access but remove offline access
Jenni Syed (Apr 06 2021 at 22:21):
Do we know how long it might take to get inferno updated? I know there will likely be several updates out of this CCG update
Robert Scanlon (Apr 07 2021 at 12:54):
Yup! We're planning on addressing these as quickly as we can, and will remove the requirement for patients to be able to deny the offline_access scope specifically as part of our next release. Thanks for raising this issue so ONC could address the ambiguity, and I appreciate the patience.
Ricky Bloomfield (Apr 07 2021 at 17:11):
Thanks, @Jenni Syed and @Robert Scanlon! I came here to post the same thing but you're all over it!
Last updated: Apr 12 2022 at 19:14 UTC
