FHIR Chat · Granular Scope Approve / Deny Reporting · smart

Stream: smart

Topic: Granular Scope Approve / Deny Reporting

---

Gino Canessa (Jul 10 2020 at 21:22):

I've been mulling and discussing the idea of telling apps about scopes being approved or denied (it was a topic on the last call). So, I thought I'd bring it up here for further discussion.

We all agreed that having it in the spec adds complexity, and I am trying to get an idea of how useful it is to offset that. The TL;DR is that I'm not seeing it. Also, apologies in advance for the long post =)

• Scenario 1:
  • App asks for scopes A, B, and C.
  • User grants A and B.
  • Fork:
    • App knows it was denied C
      • App has information that user denied C
      • App assumes data is incomplete
    • App does not know it was denied C
      • App assumes it has all of scopes A, B, and C
      • App still can't assume it has all data, since there are external reasons it may be incomplete

In either case, the App has to assume there can be data missing, because there are reasons beyond scope/auth that may cause incomplete data.

• Scenario 2:
  • App asks for access to Observations
  • Server is fancy, and allows the user to select exactly which Observations (via policy, selection, whatever) this App gets access to.
    • How can this be communicated?
  • App uses the data it gets, but cannot assume it is complete.

So again, the App may or may not receive records, but cannot make assumptions of completeness.

In general, servers cannot provide enough information to clients to say what is missing, since that would leak information. So, best practice is that Apps should always assume data MAY be missing, and auth/scope is just one possible reason.

With all that in mind, the biggest difference I see is that if the App doesn't get a record it is expecting AND it knows that scope was denied, it could prompt the user to re-auth... But if an App doesn't get data it's expecting, that's a common solution anyway (e.g., the user workflow could/would look the same).

Thoughts? Pieces I missed?

Josh Mandel (Jul 11 2020 at 13:24):

I agree there's a ton of complexity here. The issue of graceful degradation is one that apps must be able to handle irrespective of what the scopes say (though @Jenni Syed I'm interested to know if you see this differently).

The main benefit I see to returning a scopes list to the app is so in certain cases where the app is allowed to learn about denials, the app can explicitly re-prompt a user with a message like "you chose not to share your vital signs. Please re-authorize here if you want to use our BP calculator."

Josh Mandel (Jul 11 2020 at 13:29):

Such warnings can help recover from some situations where the user accidentally denies specific scopes. But these warnings can also be naggy and unwelcome. Furthermore, even if no explicit return scopes are communicated by the server, an app can approximate this "mistake correcting" behavior with messages like "we're not seeing any blood pressure results in your chart. if you chose not to share but are now ready to change your mind, click here to re-authorize."

Jenni Syed (Jul 11 2020 at 14:07):

Technically, this behavior isn't really something we get to "choose" to include, depending on the behavior of the server. The OAuth 2 specification already calls this out:

The authorization server MAY fully or partially ignore the scope
requested by the client, based on the authorization server policy or
the resource owner's instructions. If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted.

Jenni Syed (Jul 11 2020 at 14:07):

https://tools.ietf.org/html/rfc6749#section-3.3

Jenni Syed (Jul 11 2020 at 14:08):

The massive complexity comes in when your scopes are so specific as to start causing privacy concerns, which makes us question that "MUST"

Jenni Syed (Jul 11 2020 at 14:08):

This is another reason I think we should keep scopes "broader" and the very granular, per observation, per loinc (not category) type consent needs to be somewhere else

Jenni Syed (Jul 11 2020 at 14:10):

My graceful degradation (progressive enhancement? eh, you choose :)) comments are more for scenarios where the server is likely to 403 the request, which is what you should do when access is denied based on the scope not being present. And then apps not handling that error

Jenni Syed (Jul 11 2020 at 14:11):

The scenarios that get complex, where data is "hidden," aren't the things we do communicate to the app typically, because the user themselves may not have privs, or the user may not have consented to share (or the org doesn't). And yes, this means that apps need to understand generally that they may not see the full picture

Jenni Syed (Jul 11 2020 at 14:12):

This is also the friction often between patient privacy advocates vs. clinicians that want to make sure they have all the info to be able to properly treat the patient - the APIs aren't the first place this is present. This is present within EHRs themselves as well

Jenni Syed (Jul 11 2020 at 14:15):

Also, this isn't unique to healthcare, though obviously there are very different impacts :) Facebook allows you to grant apps privs, but also lets you hide specific posts from people/groups/etc. Those posts aren't really hidden by scopes - and they definitely don't tell grandma/mom/family that you hid your 21st birthday pics and posts from them :)

Jenni Syed (Jul 11 2020 at 14:21):

And this goes back to the other recommendation I referred to: apps cannot assume "no data" == negative. Just like a doctor who is getting ready to perform a treatment that may conflict if the patient has certain conditions - if they see no evidence of the negative or positive result in the record, they aren't going to assume a negative. They will order the test (or ask the patient) before making a decision. Apps should do the same.

Josh Mandel (Jul 11 2020 at 14:22):

Thanks! I agree with your points here and would like to formulate a plan. Given your notes here:

Josh Mandel (Jul 11 2020 at 14:23):

1. there is a question about what apps can ask for. The "request language" needs to support some pretty decent granularity, in my view -- and I'm assuming that scopes are the place to put this request. Agreed?

Josh Mandel (Jul 11 2020 at 14:23):

2. there is a question about what detailed internal policies a server can/will enforce. I'm assuming we (Argo 2020 Granular Data project) are not trying to standardize this at all. Agreed?

Josh Mandel (Jul 11 2020 at 14:23):

3. there is a question of what approval decisions are communicated back to an app. I'm assuming an app always needs to consider treat these "response language" statements as a hint (because policy details from (2) can always silently override). I've been assuming scopes are the place to put this response. Agreed?

Jenni Syed (Jul 11 2020 at 16:32):

Agree with 2and 3. Agree with 1 with the caveat that I don't think that scopes should go lower than categories of data :blush:

Jenni Syed (Jul 11 2020 at 16:33):

And labels and tags can be categories, but we should include guidance around how precise that should go.

Josh Mandel (Jul 11 2020 at 16:52):

Okay. And how would you feel about a solution for (1) where the SMART 2.0 IG just described granularity at the level of categories (/labels/tags, as you suggest) but with a syntax that is extensible (e.g., a list of query parameters)?

John Moehrke (Jul 13 2020 at 14:50):

good discussion. I propose that the additional vector we add to current SMART is ConfidentialityCode (6 non-overlapping risk codes) + Sensitivity (categories of sensitivity). We could pick a valueset of the sensitivity, as some of these vocabulary are less useful or less clear. We don't require data to be labeled (i.e. .meta.security might be filled but not needed); leaving it up to the resource server API to filter based on any internal mechanics, where that internal mechanics might leave evidence around but might not. These internal mechanics might use loinc, might use ontology, might allow human tagging, etc...

Jenni Syed (Jul 13 2020 at 15:39):

@Josh Mandel I'm good with that structure, though I think we should call out anti-patterns. EG: don't use "code" field within scope? I'm actually curious what other params we think would be good that wouldn't start to get so precise to start leaking privacy concerns. Might be a place to look at the "common" params and do some tests on what we think would and wouldn't be good to help guide some of our wording?

Josh Mandel (Jul 13 2020 at 16:07):

Thanks @Jenni Syed, @John Moehrke. I think we're getting somewhere. A couple of notes:

• I'm wary of decoupling sensitivity-based scopes (like _security=XX) from the tags present in the FHIR data themselves, though I agree we can leave this as a server decision. My recommendation would be: if your server is clever enough to match certain resources to a "_security=XX" scope, then it should also be populating .meta.security with "XX". This also allows for flow the other direction: if your server is flexible enough to let users assign .meta.tag values to resources, these should be addressable in the scope system.

• We might disagree on whether scopes with code= are an anti-pattern. Like, I was assuming Argonaut IG might wind up explicitly defining a scope for US Core Smoking Status like patient/Observation?code=http://loinc.org|72166-2. If we won't define it this way (aligning with the US core guide data requirements), how should we define it?

John Moehrke (Jul 13 2020 at 17:55):

im not against requiring the .meta.security tagging. I just think it is not necessary to make progress. I am also not against _security parameter like expression, but that is a query parameter not a scope; where scopes would need to address all kinds of access, not just query.

John Moehrke (Jul 13 2020 at 17:58):

I am also not against use of some loinc based category codes. These can be used in .meta.securty too, used there they are more consistent ABAC, vs the fact that not all clinical resources have a .category --- however I think it needs to be a very well defined sub-set. I think much of the reason DS4P is seen as hard to implement is that it is a very expansive and difficult set of value sets. A flat set of a dozen clinical codes is far more executable.

Jenni Syed (Jul 13 2020 at 18:00):

@Josh Mandel my concern is that I'm not sure:
1) That an auth server should need to be a terminology server to understand what codes are "ok" and what aren't and
2) Saying I only want social history using code is not really much different than saying I only want heart rate for vitals. I don't know that it should be done via scope... unless we can find something more general/that isn't also used for sensitive data

Josh Mandel (Jul 13 2020 at 18:14):

OK, backing up: do you agree that granular controls needs to support things like "only my smoking status" (given that this is one of the US Core data elements)? And if so, is your preferred route to add a new category? And if so, should this bubble upstream into US Core so that the US Core IG requires populating that as Observation.category?

Josh Mandel (Jul 13 2020 at 18:15):

I don't know that it should be done via scope

And for this, are you suggesting an additional/complementary way for apps to request specific data? This hasn't been on the radar yet, but I'd like to understand what specifically you'd be proposing.

John Moehrke (Jul 13 2020 at 18:21):

we could provide the pathway in the scope where the authorization denial could be communicated, this would be usable when the app is mostly trusted to know that it has been denied access; while allowing the authorization decision to have other apps that it doesn't trust to know why they were denied. Defining the method of communicating the scope restriction is interoperability enabling; forcing this mechanism to be used is the problem. Some apps are trusted more than others, this is just reality.

John Moehrke (Jul 13 2020 at 18:21):

it could even be a user decision... user, you just denied this app some data that it has asked for, can I tell the app or should I not let it know?

---

Last updated: Apr 12 2022 at 19:14 UTC