Scope support for profile granularity

[Ken Sinn]

Hi everyone,

Wondering if there's a way to constrain the scope on an OAuth2 token to a specific profile of a resource.

Consider a server of Observations, which include both blood/lab work as well as mental health assessments - these are distinguished by their conformance profiles.

The patient wants to only issue authorization for an app to access his blood/lab work Observations, but not his mental health assessment Observations.

Profile seems to be an ideal way to distinguish these -- e.g. in a FHIR search, the _profile argument would be used to distinguish between the two.

Is there something similar in scope definitions for SMART on FHIR? (or maybe even the HEART Profile for OAuth2?)

Thanks!

- Ken

[John Moehrke]

Hi Ken

This is defined in the Consent resource. I think HEART has some support given they have support for security tags. There is interest in improving the SMART support in the coming year. Looking forward to your participation.

I would advise against use of profile tag. It is similar but different in use intention.

John

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ken Sinn]

Thanks for the response, John.

So if we wanted to use the OAuth2 scope element (/patient/Observation.read) to limit access to only some types/classes of Observations (based on profile type) and not other types of Observations, that's not possible except with the use of Security Tags and a Consent Validation/Enforcement Engine? There are no native way to handle/support that in OAuth2/SMART at the moment?

As a practical use case, if a widget/applet is only supposed to retrieve/display bloodwork labs, there's no way to restrict its OAuth request token to just a specific profile type of Observations?

[Josh Mandel]

The use case is clear/important, and you are correct that it is not addressed in our scope language today. It's something that we have left to a future revision.

I'm thinking it might be worth introducing some new syntax to support profile-targeted scopes like "patient/Observation[http://example.org/profile-for-obs].read" for profile specific access. but to do this properly we would want to indicate that a server would be responsible for knowing which resources fit which profiles -- there might be explicit profile tags on the resource instances or there might not.

[Michele Mottini]

If we are talking about patient apps I am not sure I agree. I think that the current scopes are already too much for that. 

App authorization screens are something like this:

I would not expect most patient to even read that list - not to mention actually understand the detail (https://blog.codinghorror.com/teaching-users-to-read/). A general purpose 'your clinical data' (= patient/*.read) would be enough.

  - Michele

  CareEvolution Inc

[Steven Deng]

At https://openid.net/specs/openid-heart-fhir-oauth2-1_0-2017-05-31.html#rfc.section.2, HEART defines scope := permission/resource.access

there are samples where people adopt URNs (RFC3986) as scopes like Google API https://developers.google.com/identity/protocols/googlescopes

So, I am wondering if we can extend the HEART definition to scope := profile/permission/resource.access. In the case of Observation, we can then use

https://example.org/profile-for-obs/Observation.read

[Steven Deng]

sorry, the sample scope lost the permission part, it should be: https://example.org/profile-for-obs/patient/Observation.read

[Josh Mandel]

I didn't mean to distract with syntax -- I was just trying to be concrete with an example of what profile-based restrictions could look like.

Michele, your point is well taken, which is part of why we haven't pushed for this kind of thing strongly yet; other concerns are the variability of support across systems, and the difficulty knowing which profiles actually apply to a given resource in practice.

Another pragmatic possibility (but less expressive, less general) is to align scopes with data categories (e.g., in the US we have regulations defining distinct categories for lab results vs vital signs, and these aren't very fine-grained, but at least they're possible to explain in an authorization flow). 

[John Moehrke]

Josh,

The security workgroup have defined an abstract operation that inspects the data looking for various sensitivity topics, so that the resource could be properly tagged. This is defined as a Security Labeling Service (SLS). This abstract service would be implemented with local policy on what topics to look for. This operation might be based on CDS logic. The expectation is that security geeks are not good at medical information, so we pushed this into a service. The idea is that this service would be architected into a solution so that the security tags are accurate to the policies 'currently' in place.  One possibility is that this is a service orchistrated when resources are created or updated. One possibility is that it is orchistrated during return of a Bundle, where it is possible data might be eliminated from a bundle if too sensitive. etc,.. etc... etc...

see http://www.hl7.org/implement/standards/product_brief.cfm?product_id=360 

It is possible that a possible implementation of this Security Labeling Service (SLS) could use FHIR StructureDefinition profiles. However I think that profiles don't have as good of a capability to detect the fine details that differentiates the various privacy sensitive topics. This is why we looked to CDS to do that service work.

I am noticing that we never wrote anything about this on the security pages of the core FHIR specification.  I think that working through this would be a good exercise.

John

[Steven Deng]

Michele's concern is about the policy settings on the resource server side, for a patient app, if the security/privacy policy does not need go that level of detail, then patient/*.read might be good enough. However, protocol level, there might be a need to support other type of use cases. In the case of practitioner apps, permission set is not decided by the requester, so you might not even have to show the requester the consent screen. The need for scope to have data category as Josh mentioned above still exists. e.g.

We have repositories for both Laboratory Data resource(Lab Result Repository)  and Imaging results resource(Diagnostic Image Report Repository), those two resources are both using Observation with different profiles. Practitioners are granted permission based on their entitlement of individual repository (we call domain), during the authorization process, if the scope does not contain this information, then we have to use i.e an extra claim in the authorization request/response to reflect the same. It is doable, but ideally we want the resource server can make decision with scope alone.

Regards,

Steven

[John Moehrke]

We all agree that there is opportunity for improvement in the SMART scopes. The question is what is the best next step? There is infinite possibilities. 

Some proposals I have put forward: Both are radically different proposals to solve similar issues. 

* https://healthcaresecprivacy.blogspot.com/2017/05/fhir-oauth-scope-proposal-using-fhir.html

* https://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html

I have also heard what seems like a complex one, where the scope uses the FHIR Consent resource as the structure. I guess it could just point to a Consent resource... seems like a bigger step than we should take, right?

We should also consider the HEART model, that separates privacy decisions from business rules decisions... it is simply a model of cascading OAuth, a use of User Managed Access (UMA). I think this is an interesting architecture (cascading OAuth), but it doesn't overall solve the scope problem, it just separates it into different decision engines. right?

What other proposals are written so that we can evaluate them?

John Moehrke - Architect: Standards - Interoperability, Privacy, and Security
CyberPrivacy – Enabling authorized communications while respecting Privacy

IHE Co-Chair IT Infrastructure Planning

HL7 Co-Chair Security WG, FHIR FMG, and FHIR facilitator

FHIR Foundation founding member

HITRUST Certified CSF Practitioner

Employee of ByLight Professional IT Services -- Contractor to VHA MyHealtheVet 
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com 

https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
Postel's Law: Be strict when sending and tolerant when receiving

[Michele Mottini]

We all agree that there is opportunity for improvement in the SMART scopes.

Agreed  -  I would like to see them reduced to patient/*.read, patient/*.*, user/*.read, user/*.*. 

  - Michele

  CareEvolution Inc

 

[Isaac Vetter]

>We all agree that there is opportunity for improvement in the SMART scopes.

Agreed! 

We've gotten feedback that adoption of cloud-based SMART apps by health systems actually requires finer-grained scopes. Observation, especially, is incredibly broad for provider apps. 

HIV lab results are exposed to apps with the same user/Observation.read scope as simple weight or gestational age! This seems crazy to a CISO.

Perhaps a solution to this problem is reassuring the CISO through a federal ruling stating that lumping all Observations is appropriate. Perhaps, not.

Ken Sinn's initial question is about scoping to a FHIR profile. We're concerned that a proliferation of FHIR profiles will counter-intuitively hamper interoperability by increasing the diversity of resource implementations across both servers and clients. In lieu of a profile-based authorization scoping system, I'd like to suggest two practical enhancements to SMART's scopes -- 

1. Further specifying the FHIR interaction being authorized, instead of the less granular [read|write]. For example, splitting patient/Observation.read into patient/Observation.read & patient/Observation.search.
2. Identifying FHIR “sub-resources” – or logical groupings of the same content within a FHIR resource. Specifically, FHIR’s category element (as Josh suggested) may be an excellent candidate for identifying where in the specification single resource covers a (too?) large domain.

For example, FHIR’s Observation already divides into eight distinct categories. In the above (admittedly, contrived) example, gestational age is provided in Observation’s core-characteristics category, weight in the vital-signs category, and the HIV lab result in the laboratory category. I think we should standardize and enhance our representation of scopes to something like: patient/Observation-vital-signs.read & user/Observation-laboratory.create.

 

While Condition includes a similar category, other resources do not. Does that mean that they’re an appropriate breadth for authorization? If not, is there a reasonable, alternate method that logically split them into distinct scopes?

Michele, I see the translation between the technical ("protocol-level") OAuth2 scopes, and their presentation to a patient to be up to the OAuth2 server. A good AS should present these technical scopes in a way that is understandable by the user. The technical scopes presented to the app can, and probably should, be explained and summarized to the user.

Isaac

[Michele Mottini]

HIV lab results are exposed to apps with the same user/Observation.read scope as simple weight or gestational age! This seems crazy to a CISO.

Our system handle this with user permissions: only certain user can see observation or conditions coded with certain sensitive terms - I would imagine that is a common thing...? And I would imagine that FHIR apis implementation respect the permissions systems? (Our surely does)

I don't think these things have much to do with scopes - those are to authorize apps, but the possible concern is to authorize users - and that should be (hopefully IS) handled by existing permissions systems

  - Michele

  CareEvolution Inc

[Jenni Syed (Cerner)]

I don't think these things have much to do with scopes - those are to authorize apps, but the possible concern is to authorize users - and that should be (hopefully IS) handled by existing permissions systems

There are multiple use cases here. One (and the one I think SMART has been focusing on) is to define the granularity that a user grants to an app. EG: If I'm a patient opening an app that claims to track weight and exercise, and it can only ask for Observation, I'm probably a bit worried. I would like to make sure my labs etc that aren't necessary don't get sent to this app. Today, there's no way besides "trust the app" that I as a user can help make sure nefarious things aren't done with my data or to limit impact of a breach of that app's data.

Another use case, and what John has written about (as well as HEART) is often considering what the patient wants practitioners and others to be given access to. I assume these would need to play well within the authorization of a system itself. EG: If I has a patient accidentally granted access to my clinical data to someone that doesn't have access to that typically, the system still would enforce their own internal restrictions. This is a much more complicated use case to handle, as there are multiple "authorization profiles" in play: The app permissions, what the patient thinks someone should see, and what the clinical system thinks someone should see.

[John Moehrke]

Good differentiation.

In the first case. Can we imagine use of my proposal around query parameters as part of the scope? That is to say that one can grant to that app, rights on Observation, demanding that the category query parameter be 'vital-signs'... I think this is simple from the app, user, and service... but is very complex from the perspective of the authorization service. As that authorization service would need to understand a set of query parameters. It could be a degenerate set, that when asked beyond that degenerate set is a DENY response... We could define a few patterns that seem to make sense today..  This is not unlike the proposal for 'profiles', just more low-level and thus more simplifiable. 

The use of Profiles has an advantage that testing for compliance is baked into infrastructure, so using profile identifiers would be easy too. It would just require apps know about relevant profiles, or management (transparency) of similar-enough profiles is known.

Use of query parameters or profiles  is technically possible. But is it something the user would understand? 

The ABAC model that security has baked into FHIR using the meta.security tagging system has a few vectors, some of those vectors are understandable by the patient (confidentialy and sensitivity). A patient can certainly recognize normal medical data from restricted medical data (confidentiality code of N vs R).  So the user could grant confidentiality Normal to that app, thus forbidding anything else (or anything higher depending on how we want to write the rules. Confidentiality is a linear progression.)  This model does allow for basic segmentation. Putting highly sensitive medical topics out-of-reach, except to those apps given that (R) authorization. Adding confidentiality code to the scopes should be easy, it is already in HEART. This is likely not fine grain enough for the first use-case of an app, but is a vector that can be easily applied. 

I say easy, but I recognize that categorizing N vs R data is not easy, this is why security wg defined a service to do this tagging. Much like CDS-hooks, this Security-Labeling-Service (SLS) inspects the data and tags it. So much like CDS-hooks (and likely using CDS technology) this could be an orchestration service. It is not like CDS-hooks in that it is intended to modify the meta.security element of all data in a Bundle, and does not return any human readable thing. 

The second layer of vector is sensitivity, which is really the first layer that the SLS tries to differentiate from which it gets to N vs R.  This gives some understandable categorization that tends to align with the kinds of medical topics that patients and regulators worry about. Again a subset might be useful to start with, as the whole vocabulary may be problematic.

This said, there is lots that would need to be defined. I look forward to it.

 

John Moehrke - Architect: Standards - Interoperability, Privacy, and Security
CyberPrivacy – Enabling authorized communications while respecting Privacy

IHE Co-Chair IT Infrastructure Planning

HL7 Co-Chair Security WG, FHIR FMG, and FHIR facilitator

FHIR Foundation founding member

HITRUST Certified CSF Practitioner

Employee of ByLight Professional IT Services -- Contractor to VHA MyHealtheVet 
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com 

https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
Postel's Law: Be strict when sending and tolerant when receiving

--

[Keith Boone]

One of the distinctions we made in IHE a very long time ago was the distinction between typeCode and classCode, where typeCode was a detailed description of the data at a very in depth level, suitable for computing with, whereas classCode was a very high level description of the data suitable for human use.

 

This fits in some ways with the category classification on several resources (e.g., observation, condition, allergy).

 

Generally, the way I’ve handled category classification in FHIR is through value sets linked to a particular category.  So, any observation falling into my “vital-signs” value set would be classified as a vital-signs observation.  Some times this can be handled (for example for certain kinds of procedures) through hierarchical definitions of categories in a coding system (this chunk of codes descending from XYZ in SNOMED-CT are all {particular type of disease}-diagnostic procedures).

 

So, from the end user perspective, if you are looking to subset observations to a particular list, I’d say, consider using a well-defined category code (already existing in FHIR), or reference a value set with a name and a good definition.  In that way, it CAN be something the user would understand. 

 

Eventually, query parameters are testable through value sets, so this will also work with the computer.

 

                Keith

[Josh Mandel]

Great discussion  I'm interested in better understanding the distinction you're making here, Jenni. Is it mainly about the target of the delegation (sharing with an app vs sharing with, say, a provider)? From your example, that was my first impression, but I think I may have missed your real point. Because in both of these cases, limitations on what's shared might be imposed outside of the scope-based negotiation (e.g., the EHR system may impose rules limiting what's shared, or may give the user a fine-grained way to limit what's shared on top of the scope negotiation, as an explicit part of the approval UX).

One aspect of the distinction you're driving at might be: "when does a scope language need to be a complete description of access policies, vs when do we need/expect additional (out of band) policies to be in place?" Another aspect might be "what kinds of policies do we need to enable overall?  How granular, and how explainable?"

I'd love to think about a layered approach that defined a relatively complete low-level language that pure-and-native FHIR servers (think HAPI) could implement -- which might be a way to lock down API access based on full queries including parameters (e.g., a list of complete/exact API calls that can be made, with variables where needed) or even something like the full power of FHIRPath in filtering the search results defined (e.g., limiting access to only resources matching a certain filter). But on top of this, we'd want a common set of policies like "share everything" or "allow writing vital signs" that correspond to the kinds of sharing decisions that users might commonly need to make when delegating access from conventional EHR (most similar to the SMART scopes we have today, with opportunities for incremental improvements).

This sketch is probably too abstract; if there's interest, I'd be happy to write it up in the form of some concrete examples!

Best,

Josh

[Keith Boone]

Great points Josh.

 

Lest we forget, one of the things that is supposed to happen in SMART between the time that an App requests certain scopes and those scopes are granted is interaction with the owner of the resources in which they authorize use of certain resources.  If you’ve ever used an app of Facebook, LinkedIn or Twitter, you might have seen such a dialog box.

 

XYZ app wants to

  Access your e-mail address

  Access your contact list

  Make posts on your behalf

 

In some cases, you can make an all or none Approve/Cancel request, but in other cases you can turn off individual requests.  When I’m using Google or Facebook login’s to basically authenticate myself, I deny access to all the other features that the application is requesting, because it doesn’t need them to find out what my e-mail address is. 

 

So, an EHR COULD ask the user to provide further restrictions and apply those, without the app ever knowing that further limitations had been placed one it should it so choose to limit the types of observations the app was attempting to access.  There’s some benefit to this App unaware negotiation process, in that it doesn’t disclose to the app what limits have been placed on it, which is a potential for leaking information.

 

If an app knows it can access my labs, but not my XYZ data, that could be interpreted as “there’s a good change that I have some XYZ data that I don’t want you to see”.  This is in part why we say there’s nothing here (404 Not Found), when in fact, what we really mean is there’s nothing hear you are allowed to look at (403 Forbidden).

 

                Keith

 

From: smart-...@googlegroups.com <smart-...@googlegroups.com> On Behalf Of Josh Mandel
Sent: Monday, December 3, 2018 12:12 PM
To: John Moehrke <johnm...@gmail.com>
Cc: Syed,Jenni <Jenni...@cerner.com>; SMART on FHIR <smart-...@googlegroups.com>
Subject: Re: Scope support for profile granularity

 

Great discussion  I'm interested in better understanding the distinction you're making here, Jenni. Is it mainly about the target of the delegation (sharing with an app vs sharing with, say, a provider)? From your example, that was my first impression, but I think I may have missed your real point. Because in both of these cases, limitations on what's shared might be imposed outside of the scope-based negotiation (e.g., the EHR system may impose rules limiting what's shared, or may give the user a fine-grained way to limit what's shared on top of the scope negotiation, as an explicit part of the approval UX).