Stream: Security and Privacy
Topic: Fine-grained Security Policies
nicola (RIO/SS) (Jun 18 2020 at 19:36):
Just placeholder to move the discussion from devdays
Brian Gammon (Jun 18 2020 at 19:40):
Great talk today, I'm definitely interested in an extended meetup session on this topic if one transpires.
nicola (RIO/SS) (Jun 18 2020 at 19:42):
We will organize it. 40 min is definitely not enough. Let's spend 3h in the online meetup!
nicola (RIO/SS) (Jun 18 2020 at 19:42):
@Pavel Smirnov ?
Matthew Tyler (Jun 18 2020 at 19:43):
I'm interested in a meetup on this topic too. I have some thoughts and implementations to share.
nicola (RIO/SS) (Jun 18 2020 at 19:47):
The format of meetup can be a set of sessions with 5-10 min presentation or problem description + 10-20 min discussion
Pavel Smirnov (Jun 18 2020 at 19:49):
Sure, let's make a FHIR meetup for this. We can have it as one of the next FHIR meetups with this group https://www.meetup.com/HealthDev/. Please respond who is also interested and I will reach out to pick a date/time.
nicola (RIO/SS) (Jun 18 2020 at 19:53):
@Josh Mandel what do you think about meetup?
nicola (RIO/SS) (Jun 18 2020 at 19:55):
Maybe we can invite guys like https://medium.com/@justinsecurity
Josh Mandel (Jun 18 2020 at 19:56):
I'd certainly be up for it. And yeah, would be great to include Justin (he's been pretty actively involved in OpenID HEART in addition to UMA and now OAuth.xyz)
Patrick Grennan (Jun 18 2020 at 20:26):
Super interesting presentation and discussion today! I would love to join a future meetup on this.
John Moehrke (Jun 18 2020 at 21:13):
I am sad I missed it. The Security WG is happy to host this and help move things forward.
Jim Steel (Jun 18 2020 at 23:11):
I would be up for that, too. We have been building fine-grained access control stuff in our terminology server, and although our requirements are a little bit different (simpler), we would be interested in a good generalized solution
Grahame Grieve (Jun 18 2020 at 23:22):
it certainly sounds like it's time to pursue this with vigor
Matthew Tyler (Jun 18 2020 at 23:33):
How have meetups been setup before for this group?
Jose Costa Teixeira (Jun 19 2020 at 04:38):
I'm watching the video and some of those topics remind me the Permission draft discussions:
- Define a data set (like a predefined set of _elements)
- Define who can access which data for which purposes
- Define rules on resource profiles - so that these rules can be provided as part of the specification e.g. for a country regulations
- Define rules on resoure instances - when you send out the data, you also put in the envelope "this data has been allowed for these uses"
Jose Costa Teixeira (Jun 19 2020 at 04:39):
The presentation was very very informative.
This is a hot topic and I'd like to see a solution that works integrated with the GDPR requirements
David Pyke (Jun 19 2020 at 11:32):
If meetings to discuss this are set up, add me to the list of interested parties
Josh Mandel (Jun 19 2020 at 13:47):
we should definitely put together a meeting. The best model I've seen for this is the Internet Identity Workshop, which basically asks people to propose sessions in an "un conference" where are you share some work you've been doing or a specific proposal you want feedback on, and open up for discussion. Works great in groups of maybe 5 to 20 people per topic.
Pavel Smirnov (Jun 23 2020 at 21:01):
Please vote for the day/time here: https://doodle.com/poll/92kxffq5bphcv9ra. If none of the proposed times work for you please vote and send me a message with your availability. @nicola (RIO/SS) @Josh Mandel @Brian Gammon @Grahame Grieve @David Pyke @Matthew Tyler . I am sorry if I missed you, please use the same link.
Jose Costa Teixeira (Jun 24 2020 at 05:20):
most those slots are 1 to 3 am in Europe. Any chance to find something else?
Pavel Smirnov (Jun 24 2020 at 23:26):
Jose, most of the audience in the meetup group is in the US and we decided to go with the time that works for the US and Australia (morning). Nikolai plans to stay late. It is impossible to satisfy all the time zones, sorry :(
Pavel Smirnov (Jun 24 2020 at 23:27):
Pavel Smirnov said:
Please vote for the day/time here: https://doodle.com/poll/92kxffq5bphcv9ra. If none of the proposed times work for you please vote and send me a message with your availability. nicola (RIO/SS) Josh Mandel Brian Gammon Grahame Grieve David Pyke Matthew Tyler . I am sorry if I missed you, please use the same link.
Tuesday, June, 30 at 7 pm ET then. I posted the event here: https://www.meetup.com/HealthDev/events/271506022/.
David Pyke (Jun 24 2020 at 23:31):
I'm confused, it was at 7pm ET and now it's 4PM ET?
David Pyke (Jun 24 2020 at 23:34):
Nevermind, I see in the meetup it's 4PM PT.
Jose Costa Teixeira (Jun 25 2020 at 02:28):
@John Moehrke hope you can attend. And hopefully we can update the Permission use cases to show how to have these access rules in an interoperable format
Pavel Smirnov (Jun 25 2020 at 04:12):
David Pyke said:
Nevermind, I see in the meetup it's 4PM PT.
It was my mistake. 7pm ET, or 4pm PT.
Pavel Smirnov (Jun 29 2020 at 19:58):
The FHIR meetup®: Fine-grained Security Policies Beyond OAuth2 is tomorrow. There will be zoom and youtube options to join. If you are speaking or want to actively participate, please join zoom. Speakers please add your topics to the schedule here: https://docs.google.com/spreadsheets/d/15za6DXk0Cnn97CYWrZRw-1l14Hw3juKmG8bkcm9Yxh8/edit#gid=0. @Josh Mandel @nicola (RIO/SS) @Grahame Grieve @Vassil Peytchev @Mohammad Jafari @Matthew Tyler @David Pyke @Chris Grenz @k connor . I am sorry if I forgot someone.
Jens Villadsen (Jun 29 2020 at 21:01):
the timeslot chosen is REALLY bad for europeans.
Dmitry Etin (Jun 30 2020 at 14:16):
Is the meetup going to be recorded? It's rather late for Europe. And so far, there's no conference link on the meetup page either @Pavel Smirnov please advise.
Pavel Smirnov (Jun 30 2020 at 14:22):
There will be a link soon but it is going to be recorded.
Pavel Smirnov (Jun 30 2020 at 17:33):
https://www.youtube.com/watch?v=CLYB2d4akWU here is the link to the meetup broadcast
Josh Mandel (Jun 30 2020 at 23:03):
Hi everyone! Looking forward to today's conversation! Please review and add to proposed topics
Michael Lawley (Jun 30 2020 at 23:20):
We have developed a new per-resource security model (using meta.security) implemented in our terminology server Ontoserver especially for terminology operations. One of the key issues is that $expand on a ValueSet needs to respect the permissions of all involved resources (the ValueSet(s) and the underlying CodeSystem(s)). This is a slightly different use-case scenario to what is commonly discussed as the main driver is about IP/licensing and governance rather than the clinical / privacy-driven ones linking back to Patient / Practitioner(Role).
It's also made somewhat difficult because the principals ("users") involved are not Patients/Practitioners and thus don't have a corresponding FHIR Resource and cannot be put into Groups -- all of this information is thus managed externally in an OAuth2-based authorization server.
We don't have public doc on this yet (new release not yet out), but this seemed like an opportune time to share a preview of what's coming.
Josh Mandel (Jun 30 2020 at 23:34):
Interesting -- indeed!
Michael Lawley (Jun 30 2020 at 23:37):
The basic approach is that security labels in the CodeSystem http://ontoserver.csiro.au/CodeSystem/ontoserver-permissions take the form [category].read and [category].write and a user must have at least one of these in authorization token's claims. Resources with no security labels from this CodeSystem are unrestricted. (There is also an authogonal security policy regarding basic READ / WRITE access to the server that must be satisfied as well.)
Michael Lawley (Jun 30 2020 at 23:39):
At the moment, you only need write permissions on a Resource to be able to change the security labels. I'm unsure as to whether we should have a separate permission like [category].security for this.
Josh Mandel (Jun 30 2020 at 23:41):
And do permissions like [category].read get assigned to clients as scopes?
Jim Steel (Jun 30 2020 at 23:48):
+1 for "authogonal"
Michael Lawley (Jun 30 2020 at 23:49):
We currently use "permission" to refer to the things you attach to a resource and "authority" as the thing that a "Clients" (as in a user, not an App) are give.
The details of what actually goes in the token are currently in flux. Our original plan ran into problems as some well-known Authorization servers (Keycloak, I'm looking at you) have (what appear to be arbitrary) syntactic restrictions on the acceptable values in a scope (we had planned to use something like group/[category].read but / is not allowed), so we encode them differently. I don't like what we have for this at the moment, but it does need to be something that works easily with existing 3rd party services.
Brendan Keeler (Jun 30 2020 at 23:50):
Nice summary of the XYZ presentation now - https://medium.com/@justinsecurity/xyz-why-b855970fdd89
John Moehrke (Jun 30 2020 at 23:54):
as Josh explained, there is much magic... We need to determine if we are defining the standards for the API security/privacy for the purpose of interoperability; or we are defining the systems design that can do the magic. I think we need to be careful to focus on the Interop (security/privacy) function, and not get too deep in the systems design. We must be sure there is at-least one systems design that will work, but we should not be mandating a single systems design.
Josh Mandel (Jun 30 2020 at 23:55):
Agreed.
We must be sure there is at-least one systems design that will work, but we should not be mandating a single systems design.
Especially this -- I think this is still a hard "low bar" to meet.
John Moehrke (Jun 30 2020 at 23:55):
it is very hard to keep to this principle.. I am not saying it is a simplifying principle.
John Moehrke (Jun 30 2020 at 23:58):
my point is to define the interfaces, not the systems design... the how policies are written, not all the possible policies... etc...
Michael Lawley (Jul 01 2020 at 00:05):
So our model allows you to say that there are categories (groups) of resources and and a resource may be a readable and/or writable member of zero or more categories. Then users are given read and/or write permissions on category members. The FHIR SCRUD operations have natural associations to read / write as do the various operations.
Brendan Keeler (Jul 01 2020 at 00:08):
Who is involved in the GNAP project?
John Moehrke (Jul 01 2020 at 00:13):
I like the idea of learning from OAuth2, and not being constrained by OAuth2... so I am liking what this can become. If Healthcare added our complexity and community behind this then it could become what we need. I am confident OAuth2 can't meet healthcare needs in the end.. but we should be able to work with OAuth2 in the mean time.
Isaac Vetter (Jul 01 2020 at 00:14):
"OAuth doesn't really work for truly ephemeral clients, not SPAs, such as a lamba function that's spun up, requests a key does some stuff and then disappears" -- that's interesting (sorry, guys, I'm literally 5 minutes behind everyone else)
John Moehrke (Jul 01 2020 at 00:15):
how important in healthcare are ephemeral clients?
Michael Lawley (Jul 01 2020 at 00:15):
CDS Hooks
Michael Lawley (Jul 01 2020 at 00:15):
Subscription
John Moehrke (Jul 01 2020 at 00:15):
fair
Isaac Vetter (Jul 01 2020 at 00:16):
I don't know of any. A CDS Hooks service could definitely be a lambda function, but even the base spec assumes that it's been registered with the OAuth server.
Brendan Keeler (Jul 01 2020 at 00:17):
Benefits aside - is healthcare is the right industry to be the front runners for a relatively unproven, currently non-standard protocol? Would hate to march down the XYZ / GNAP path and have it be our generation's MLLP
John Moehrke (Jul 01 2020 at 00:17):
Brendan Keeler said:
Benefits aside - is healthcare is the right industry to be the front runners for a relatively unproven, currently non-standard protocol? Would hate to march down the XYZ / GNAP path and have it be our generation's MLLP
scary
Brendan Keeler (Jul 01 2020 at 00:17):
I moonlight writing horror stories, @John Moehrke ;)
Isaac Vetter (Jul 01 2020 at 00:17):
Personally, I've always appreciated exactly how minimal MLLP is :wink: , but, yeah, Brendan.
John Moehrke (Jul 01 2020 at 00:18):
hence why I placed it as working toward a future, while working with OAuth now
Brendan Keeler (Jul 01 2020 at 00:18):
Careful complimenting MLLP while in a security channel, @Isaac Vetter
John Moehrke (Jul 01 2020 at 00:18):
MLLP is perfectly secureable with mutuall-authenticated-TLS
Isaac Vetter (Jul 01 2020 at 00:19):
(ack! I thought this was the #smart stream!) SSH Tunnelling all the way, John!
John Moehrke (Jul 01 2020 at 00:19):
TLS is dead... long live TLS
Brendan Keeler (Jul 01 2020 at 00:19):
(just kidding MLLP will always be my fav)
John Moehrke (Jul 01 2020 at 00:24):
multi-dimensional -- so adorable until healthcare comes at it with 1000 dimensions (org, patient, gardien, clinician, payer, gov, police) ^ sensitivityconfidentialityclassification*compartment ^ patient rules
Josh Mandel (Jul 01 2020 at 00:43):
@Matthew Tyler Thanks for the ALFF overview today. Can you share an example here of a policy that returns "advice" on searches?
John Moehrke (Jul 01 2020 at 00:44):
XACML fully supports the @josh full magic model of pre-processing, and post-processing (obligations)
John Moehrke (Jul 01 2020 at 00:45):
look at the obligations found in the HL7 security labels vocabulary - http://build.fhir.org/v3/ObligationPolicy/vs.html
John Moehrke (Jul 01 2020 at 00:45):
and refrains http://build.fhir.org/v3/RefrainPolicy/vs.html
John Moehrke (Jul 01 2020 at 00:46):
these are vocabulary for functions... the implementation of that function is an exercise left to the implementer in the post-processing (or import pre-processing of a recipient).
John Moehrke (Jul 01 2020 at 00:48):
as vocabulary, this is extensible... and in a FHIR world needs enhancement.
Brendan Keeler (Jul 01 2020 at 01:07):
Incredible LinkedIn burn by Josh
Brendan Keeler (Jul 01 2020 at 01:07):
Gotta get a Substack Chris
Josh Mandel (Jul 01 2020 at 01:08):
I totally am looking to figure out how to get targeted notifications in LinkedIn. For the record, I follow Chris. I just don't know how to watch for updates to his page.
Paul Church (Jul 01 2020 at 01:09):
I'm not on LinkedIn at all and I feel fine
Paul Church (Jul 01 2020 at 01:12):
I have always thought that Chris's profile governed access control is a great idea - we already put all this effort into profiles, why not use it.
Josh Mandel (Jul 01 2020 at 01:19):
Yeah, it's a very clean way to reuse this work.
John Moehrke (Jul 01 2020 at 01:19):
the extensions shown in the DS4P are there to explain 'why' a specific code is found in the .meta.security.... the .meta.security is the actionable code. not these extensions
Josh Mandel (Jul 01 2020 at 01:19):
Making it work in a performant way is another challenge.
Josh Mandel (Jul 01 2020 at 01:19):
But Chris has shown it's possible.
John Moehrke (Jul 01 2020 at 01:22):
critical review of ds4p and gov IG is needed.
Josh Mandel (Jul 01 2020 at 01:24):
So one common theme from presentation and discussion today, including from Michael, Nicola, Chris: FHIR Compartments are really useful, but limited today. It'd be nice to have more tools to define compartments flexibly, including definitions by what Chris calls "traversals" like
- One hop: Patient compartment including all resources whose subject is Patient 123
- Two hops: Organization compartment including data from all Patient compartments whose Patient.managingOrganization is Organization 456
Grahame Grieve (Jul 01 2020 at 01:26):
for me, that's begging the question. For me, the real question is - and I'm sorry I missed the rest of the meeting - how much interop do we need around access control? Are we simply solving a system architecture problem for pure FHIR servers (which I also am interested in) or are we trying to do something interoperable here?
John Moehrke (Jul 01 2020 at 01:26):
it should be noted that there is an equvilant compartment concept in the security domain. We assign resources to a compartment with vocabulary in .meta.security
Josh Mandel (Jul 01 2020 at 01:27):
My take is that "we" (anyone implementing FHIR REST API services, whether "pure" or not) need a consistent way to express access control rules.
John Moehrke (Jul 01 2020 at 01:27):
do they? I don't think they do. There is a need for API defined standards, but not all access control rules
Grahame Grieve (Jul 01 2020 at 01:28):
internally consistent? Does it surface publically anywhere?
Are we looking for a FHIR+ that represents an application FHIR server such that a full solution is portable across FHIR Servers?
Josh Mandel (Jul 01 2020 at 01:28):
the rules show up in the APIs.
Grahame Grieve (Jul 01 2020 at 01:28):
... how?
Josh Mandel (Jul 01 2020 at 01:28):
Like, in OAuth you need to talk about scopes concretely.
John Moehrke (Jul 01 2020 at 01:28):
that which shows up at the API.. YES. but not all access control rules.
Grahame Grieve (Jul 01 2020 at 01:29):
it's clear how OAuth scopes show in the API, and we can talk about the requirements for that, but it's not the same as access control rules
John Moehrke (Jul 01 2020 at 01:29):
this was my point 2 hours ago that we need to be careful to define what is needed at the API interface, while NOT defining the systems design
Josh Mandel (Jul 01 2020 at 01:30):
Saying "I need access to ___" is what an API needs to handle -- and the language for writing "___" needs to be standardized for this to work.
John Moehrke (Jul 01 2020 at 01:30):
ANYONE can define a .meta.security compartment using whatever internal rules language they want
Grahame Grieve (Jul 01 2020 at 01:30):
we need to be careful to define what is needed at the API interface, while NOT defining the systems design
Well, unless we decide that we want access control to be interoperable to some degree or other
Josh Mandel (Jul 01 2020 at 01:30):
It may or may not be an HL7 project to define these, but I should clarify that the need need isn't for something in the internals of a server, it's on the edge, where a server commits to upholding a specific "contract" / policy. Interop is super important here because data is fragmented.
Grahame Grieve (Jul 01 2020 at 01:31):
so the server needs to make some computable public contract statement? what would the requirements around computability be there?
Josh Mandel (Jul 01 2020 at 01:32):
My data sit in all different servers with different capabilities; if I want any hope of bringing these data together, I need a standard way to describe the data that I need, and that means access policies.
Josh Mandel (Jul 01 2020 at 01:32):
It seems clear they need to be computable to be useful; or maybe I'm missing something.
Josh Mandel (Jul 01 2020 at 01:34):
John Moehrke: ANYONE can define a .meta.security compartment using whatever internal rules language they want
https://www.hl7.org/fhir/compartmentdefinition.html says that only HL7 can define a compartment.
Grahame Grieve (Jul 01 2020 at 01:34):
I don't follow that as a story at all. All the stories I have heard to this point - which I also have on my own - is that I have a server and I need to give admin control over access control
Grahame Grieve (Jul 01 2020 at 01:34):
how would understanding server policies, some of which I can't be allowed to know, change my ability to bring data together?
Josh Mandel (Jul 01 2020 at 01:35):
You haven't heard stories where a user is accessing her own data in a remote system that she doesn't control?
Grahame Grieve (Jul 01 2020 at 01:35):
sure but I haven't heard stories where by having a detailed understanding of the access control policies would make any difference to her
John Moehrke (Jul 01 2020 at 01:35):
Josh Mandel said:
John Moehrke: ANYONE can define a .meta.security compartment using whatever internal rules language they want
https://www.hl7.org/fhir/compartmentdefinition.html says that only HL7 can define a compartment.
I have explained that security .meta.security has a compartment concept that is aligned with the security world of compartments... this is independent (but related) to the concept in FHIR of a CompartmentDefinition
Josh Mandel (Jul 01 2020 at 01:36):
Like, wanting to delegate access to data about a specific group of patients that you manage?
Josh Mandel (Jul 01 2020 at 01:36):
Or a specific subset of your personal data?
John Moehrke (Jul 01 2020 at 01:36):
in .meta.security concept of compartment .. it is just a code... what the code means is an internal matter.
Grahame Grieve (Jul 01 2020 at 01:37):
so right now, that would be an OAuth story, right? You can grant access that way; we think that the OAuth scopes are not expressive enough, but it's not the same thing?
John Moehrke (Jul 01 2020 at 01:37):
there is a remedial vocabulary , but it is rather useless http://build.fhir.org/v3/Compartment/vs.html
Paul Church (Jul 01 2020 at 01:37):
As a patient with the right of access to my data, I want to inform my various data holders to share only certain types of observations with a certain third party application. I don't want that categorization to vary across holders.
Josh Mandel (Jul 01 2020 at 01:37):
we think that the OAuth scopes are not expressive enough, but it's not the same thing?
An OAuth scope language is something the resource server needs to interpret to make access control decisions. The ones we use today are awfully weak, and it means that every serious server is inventing its own.
Josh Mandel (Jul 01 2020 at 01:38):
These server-specific languages aren't consistent, so they're not interoperable.
Josh Mandel (Jul 01 2020 at 01:38):
That means connecting a client to a server is a project instead of just a decision.
John Moehrke (Jul 01 2020 at 01:38):
Paul Church said:
As a patient with the right of access to my data, I want to inform my various data holders to share only certain types of observations with a certain third party application. I don't want that categorization to vary across holders.
agreed.. this is the set of use-cases that the Consent resource is trying (not well due to lack of community engagement).
John Moehrke (Jul 01 2020 at 01:39):
and we also have an emerging group wanting a Permission resource that is not specific to a 'consent' act.
Grahame Grieve (Jul 01 2020 at 01:39):
ok so I'm fine if we say that we're trying to beef up our language for authorization - which is what this is. I just think that's a totally different thing that access control, and the kind of things Nicola was talking about
Josh Mandel (Jul 01 2020 at 01:39):
I'd suggest the lack of engagement on consent might reflect that the proposed solutions aren't close enough to what the community wants.
Josh Mandel (Jul 01 2020 at 01:40):
I don't think these defined layers are super helpful, but I'd be interested to hear other perspectives.
John Moehrke (Jul 01 2020 at 01:40):
the community can come in and DRIVE this. all it takes is 2 people to show up to have majority
Grahame Grieve (Jul 01 2020 at 01:40):
well.. Consent is something different to most of what we are wanting here. I think that the lack of engagement is due to the gap, and also that the consent work is trying to make computable the existing paper/legislative mess
Josh Mandel (Jul 01 2020 at 01:41):
the community can come in and DRIVE this. all it takes is 2 people to show up to have majority
You need something close, for people to react to and build on. Otherwise they'll keep inventing. Like we're hearing about here.
Grahame Grieve (Jul 01 2020 at 01:41):
I agree that the boundary may not be super helpful, but there's a scope/complexity issue at the heart of this
John Moehrke (Jul 01 2020 at 01:41):
Consent is a very specific use-case... where consent applies... but as we expand that concept to Permission we are getting closer to the set of use-cases that are the discussed Compartment need
John Moehrke (Jul 01 2020 at 01:42):
it is an access control Permission.. might be because of consent, might be because of some business arrangement
Paul Church (Jul 01 2020 at 01:42):
I think if there was a robust and well adopted consent story, then it would connect to this discussion. But it's not a blocker.
John Moehrke (Jul 01 2020 at 01:44):
consent is being driven from too constrained workgroup (CBCP) which only is considering the needs around patient privacy consent.. and not broader need of Permission (compartment)
Grahame Grieve (Jul 01 2020 at 01:44):
the underlying language is similar, I think. Which is where Justin's XYZ story was relevant. Though I kind of suspected that XYZ langauge still wasn't rich enough
John Moehrke (Jul 01 2020 at 01:46):
well, re-inventing the 15th security policy standard is always inviting.
Isaac Vetter (Jul 01 2020 at 01:46):
As a patient ... I want to inform my various data holders [and] don't want that categorization to vary across holders.
Note that none of the demonstrated systems actually enables a patient to make a choice. From my perspective, it seems that the "server-specific languages" are simple a technical end-run around the "existing paper/legislative mess"; thereby, pushing the actual hard part on the doctor's office.
Josh Mandel (Jul 01 2020 at 01:47):
that sounds off-base to me -- the whole point of a language for these rules is that they can be automatically applied, and the doctor's office doesn't have to do a thing.
Isaac Vetter (Jul 01 2020 at 01:48):
who uses the language to write the rules, Josh?
Isaac Vetter (Jul 01 2020 at 01:48):
In AidBox? In MS? in ...
Josh Mandel (Jul 01 2020 at 01:48):
Clients and servers... communicate using this langauge.
Josh Mandel (Jul 01 2020 at 01:48):
Just as with SMART scopes in OAuth.
Josh Mandel (Jul 01 2020 at 01:49):
That's a too-simple example of such a language.
John Moehrke (Jul 01 2020 at 01:49):
a blood-pressure application should not need to think about this complexity
Isaac Vetter (Jul 01 2020 at 01:49):
@nicola (RIO/SS) to pick on you as an example, who typically uses your really powerful, programming language UI for configuring access control rules?
Grahame Grieve (Jul 01 2020 at 01:49):
I think Isaac has a point.. the real world mess will make a mess of whatever we do, and the cleaner what we do is, the more mess we externalise
Josh Mandel (Jul 01 2020 at 01:50):
@Isaac Vetter I'm not sure what you want to convey with that image.
Josh Mandel (Jul 01 2020 at 01:51):
The context on that image: represents one example of vendor-specific langauge @nicola (RIO/SS) presented as part of an information-sharing exercise on today's call.
Grahame Grieve (Jul 01 2020 at 01:52):
it's a language very focused on the system architecture; it would not be relevant for the sharing story discussed above
Josh Mandel (Jul 01 2020 at 01:53):
I mostly agree @Grahame Grieve ; it's just an example of something that has actually been built today. But it's certainly relevant, because it gives me a way to say "Allow access only to observations about patient 123 with such-and-such characteristics..."
Josh Mandel (Jul 01 2020 at 01:55):
The aim would be to make these descriptions in terms of FHIR API and data models, so they have a chance at being reusable.
Paul Church (Jul 01 2020 at 01:56):
I think the vendor discussion on the call is very useful, even if it's not an HL7 standard or patient facing it's going to be an obstacle to adoption if each server vendor has a slightly different domain specific language for configuring access policies.
John Moehrke (Jul 01 2020 at 01:56):
there are a set of interop definitions that we need. This Compartment/Permission/Consent is just one... different from the app authentication (SMART) discussion
John Moehrke (Jul 01 2020 at 01:56):
BY ALL MEANS OVERWHELM US!!!!!!
Josh Mandel (Jul 01 2020 at 01:57):
We'll do our best. Decision is to take design / test implementation discussions to this channel here, unless y'all kick us out ;-)
Grahame Grieve (Jul 01 2020 at 01:57):
I actually do think we should go here; if we're going to move away from making toy apps interoperable to making real world solutions interoperable (as opposed to classic B2B integration, or 1-way C2B channels), then we need an interoperable security model.
Josh Mandel (Jul 01 2020 at 01:58):
Gah, I'm now totally unable to summarize your perspective Grahame :p
Grahame Grieve (Jul 01 2020 at 01:59):
in my mind, it's a FHIR+ thing - not something that legacy vendors would ever buy into, but something that the new FHIR-from-ground-up servers need to create a new market. So if those of us making those would commit to support a common language/API for managing this, I think it would be good.
Gino Canessa (Jul 01 2020 at 01:59):
Great stuff, thanks everyone!
Josh Mandel (Jul 01 2020 at 02:00):
Thanks. That's interesting at any rate. So if it's a "FHIR+" thing, the question becomes what piece of it reflects back into real FHIR -- because I still think SMART 1.0 scopes aren't up to the task.
Grahame Grieve (Jul 01 2020 at 02:00):
I'm glad you can't summarise my perspective; it's split between what I want individually, and what I want as product lead. I want the community to want this, but we can't do that by fiat - hence why I'm making sure we understand where we are, and why, and the ramifications of where we might go
Grahame Grieve (Jul 01 2020 at 02:01):
and it makes total sense that if we did a FHIR+ thing around security, the underlying security language would be consistent across scopes and the permission resource
nicola (RIO/SS) (Jul 01 2020 at 02:37):
@Isaac Vetter aidbox is FHIR backed and developers who are building next EHR use this DSLs to define Permissions and show nice checkboxes list - like epic does ;) One of them is well known json schema another is well known SQL. @Grahame FHIR server is useless in production unless it provides access control, User to Patient/Practitioner linkage etc.
Some of this DSLs should stay vendor specific for pragmatic reasons. The good thing standard can do is define extension points and give vendors to make it work thro practice and after that probably incorporate best ideas back.
That's how sql, css and other successful standards do.
Michael Lawley (Jul 01 2020 at 02:41):
@John Moehrke I believe the compartment concept is effectively what we've done for Ontoserver.
nicola (RIO/SS) (Jul 01 2020 at 02:42):
I'm really scared some overspecification signs comming not from practice side
Michael Lawley (Jul 01 2020 at 02:44):
What we don't have is a way to connect our notion of compartments with FHIR's Group and then to Group.member.entity[Person] (because Person is not an allowed reference) (where Person would be fhirUser).
nicola (RIO/SS) (Jul 01 2020 at 02:46):
We turn fhir ref restrictions into documentation in aidbox for same reason ;)
nicola (RIO/SS) (Jul 01 2020 at 02:48):
Closed-world design just does not work in real-world
Michael Lawley (Jul 01 2020 at 02:49):
If we had that, then the authorization mgmt could be done entirely within the FHIR API and we wouldn't need to push stuff through the OAuth token. OTOH, putting the AuthZn story in an external server means we've only one place to manage group membership and that can be shared across FHIR servers.
nicola (RIO/SS) (Jul 01 2020 at 02:51):
So we need SCIM User modeled in FHIR
Michael Lawley (Jul 01 2020 at 02:53):
Yes, I'm now looking to SCIM if we need an API for our use-case. At the moment we only need a UI :-)
nicola (RIO/SS) (Jul 01 2020 at 03:02):
Just empty User resource may be really better
nicola (RIO/SS) (Jul 01 2020 at 03:04):
with a couple of predefined refs to pt and pr
Jose Costa Teixeira (Jul 01 2020 at 05:35):
I'm watching the video and IMO the data for enaling Access Control should be more interoperable if we want to ensure interoperability on a system level, not only on a server.
Jose Costa Teixeira (Jul 01 2020 at 05:37):
For Belgium I'm trying to have a decent GDPR-compatible implementation, with things like:
- Queries pass through the access control (e.g. some users cannot search by national ID number)
- Data Subject rights (e.g. erasure, knowledge of processing) pass through some decision as well (e.g. patient requests do not erase vaccination data)
- Response is also passing through the same filter (e.g. if the result data set has less than 5 patients, we don't provide that dataset)
- consent is only one of the lawful basis of processing, we have others
- purpose of use is essential part of the data set for decision
- Data element identification can be done on a) Segment, b) element type, c) element instance
- This is all metadata (I'm looking at the Permission resource, but other solution may meet the requirements) and that metadata should be interoperable - for example a patient may know (some of) the permissions that apply to their data - including the specific instances he has allowed or not.
And we currently feel the pain of having access control buried in a technical implementation - which makes controlling or changing hard to manage.
Jose Costa Teixeira (Jul 01 2020 at 05:39):
From discussions in the Security calls, we do not want to replace e.g. xacml, we want the permission metadata (input to xacml engine) to be consistent/traceable
Jose Costa Teixeira (Jul 01 2020 at 05:40):
@nicola (RIO/SS) I think your AccessPolicy resource is what Permission is expected to do.
actually, Permission would express a policy or an instanciation thereof
Grahame Grieve (Jul 01 2020 at 06:23):
@Michael Lawley if I designed a FHIR+ with a security layer, I'd start by including SCIM for the stuff SCIM does, and focus on how you bind between the 2
Matthew Tyler (Jul 01 2020 at 18:58):
Josh Mandel said:
Matthew Tyler Thanks for the ALFF overview today. Can you share an example here of a policy that returns "advice" on searches?
I'd like to put together a more detailed presentation and demo for something in the near future. I'll be out for the next week, so perhaps a few weeks from now or timed with our other regular meet ups.
Nancy Lush (Jul 02 2020 at 16:39):
Multiple workgroups have already done the deep-dive into this topic and there are several implementations. There are also meaningful FHIR+ use cases. (Grahame, you are correct in that this is a different paradigm and needs to be thought of differently.) Several years ago, we still had several blockers. We are now at that inflection point where this technology could be available now. Two recommendations:
- We (Patient Centric Solutions) would be willing to do a demonstration and explain why we made certain decisions at this stage in our product implementation.
- Convene a meeting that includes other experts on this topic so that we can accelerate understanding.
Jenni Syed (Jul 06 2020 at 16:33):
Coming in waaaay late here (thanks holiday weekend) but I think we need to keep the application authorization language separate from the user authorization language. SMART 1 made that "easy" (in that it allowed whatever existing user policies to be combined when the user was in the workflow) and the OAuth 2 scopes should focus on what they do best - limiting what the app can do on behalf of the user. It shouldn't ever be able to go beyond what the user can do.
Jenni Syed (Jul 06 2020 at 16:34):
IE: The OAuth 2 scopes aren't focused on user access. If a patient wants to say that Doc X can only do Y - that's not OAuth... that feels ... weird
Jenni Syed (Jul 06 2020 at 16:34):
That is more consent based :) And yes, we haven't tried to represent that beyond basic patient consent today in the standard...
Jenni Syed (Jul 06 2020 at 16:35):
And haven't attempted to build out RBAC-type security (or really anything) for "provider" users today at all
Grahame Grieve (Jul 06 2020 at 21:27):
it seems to me that we all agree to this - these are separate problems, and very definitely separate spaces. But we also think that the underlying language - the way we are expressing the rules - should be consistent between the 2 purposes
Jens Villadsen (Jul 06 2020 at 21:48):
Having glimpsed at this thread I just want to add my 2 cents: The setup that I've worked on for the past 1.5 years is a national FHIR greenfield project, meaning that I have had the luxury of getting to define the security model being a combination of RBAC and ABAC. One of the requirements is to bridge SAML and Oauth which I imagine is a pretty common use case. The bridging part enables users get an initial set of RT/AT's with the roles from the SAML login. When (clinical) users wants to go into details of a certain patient, a new set of RT/AT's must be handed out based upon their affiliation with the patient (this is the only way to do it as I see it when users come from an existing SAML federation and you don't wan't to force users to log out, in order to elevate their rights if you can verify the correctness of this within the system). This is not needed when patient themselves access their record as their RT/AT's are fixed to themselves (much like SMART). This setup also uses the compartment definitions to some extent (- which I would encourage to have careteams added).
PKumar (Jul 22 2020 at 12:09):
We are building FHIR APIs on Azure FHIR. However, what are the best practices to ensure the security is handled? I know that Azure is using AD authentication but I am looking more from the FHIR literature, what are the resources that I can use to enable better security/restricted access/managing permissions?
Thanks in advance!
John Moehrke (Jul 22 2020 at 12:22):
see http://build.fhir.org/secpriv-module.html
PKumar (Jul 22 2020 at 13:32):
Thanks @John Moehrke
I have gone through the link content. I see that Consent, Provenance and Audit are available. But in a case when I want to give access to particular resource lets say observation resource to client A with edit permission, I can create consent accordingly. But in the actual implementation workflow how does this be taken up? Does the client request first be validated against the consent resource API and if the request is satisfied with the consent, then should I give access to corresponding patient resource API?
John Moehrke (Jul 22 2020 at 16:46):
That is an implementation detail that is beyond the scope of the FHIR core standard. The FHIR core standard is a specification of the API definition, not the systems design behind that API.
John Moehrke (Jul 22 2020 at 16:47):
That said, there are some security implementation guides that are being developed. SMART-on-FHIR is the only one that is available today in published form, and has implementations built into some of the reference implementations like HAPI.
PKumar (Jul 22 2020 at 17:12):
Thanks for the response @John Moehrke
Should I consider consent, provenance resources are used as APIs to let the incoming client aware of the rules that we are going to check upon? so that the client can accordinlgy plan to send requests to our FHIR server?
Lets say I have FHIR server and exposing Patient API. I will also expose consent API that has details about what is required to access Patient data. Now the client who wants to integrate my Patient API, would first likely to hit consent API, understand the rules and accordingly make the API calls to ensure the successful transaction.
Thanks in Advance, I am fundamentally confused as I am new to this concept. Your help is much appreciated.
John Moehrke (Jul 22 2020 at 18:03):
There are many security models. The one you mention is possible. There is no manditory security model. So it is up to you to define the security models you will support.
John Moehrke (Jul 22 2020 at 18:04):
In the case of SMART-on-FHIR... the consent tends to be managed transparently to the client and OAuth; handled transparently within the Resource Server. That transparent access control decision/enforcement might use Consent, might use some internal logic.
PKumar (Jul 23 2020 at 09:15):
thanks very much @John Moehrke
If I go with a separate portal for my customers who access the APIs, then how would they login to my portal?
should that be through Azure AD (or any open auth 2.0) and in backend we add it to SMART on FHIR? or does SMART on FHIR can be a kind of authentication to be shown in the front end as a lable and through that user can login?
John Moehrke (Jul 23 2020 at 12:48):
possibly @Josh Mandel can help with implementation details on how a user based that uses Azure AD can be authenticated using OpenID-Connect inside of the SMART-on-FHIR use of OAuth.
PKumar (Jul 27 2020 at 11:55):
I was going through the security labels but facing difficulty to comprehend the use case on when to implement security labels and does these labels play part in resource level authentication workflow? Looking forward for response, Thanks!
John Moehrke (Jul 29 2020 at 13:17):
I am not sure what specifics you need. I do have some articles I have written on my blog
John Moehrke (Jul 29 2020 at 13:18):
and I have a tutorial I teach in HL7 education
PKumar (Jul 30 2020 at 09:12):
Thanks @John Moehrke I will go through the links
Louis St-Amour (Sep 24 2020 at 15:35):
Hi folks, I recognize the talk was many months ago, but @Josh Mandel mentioned different ways of evaluating policy for accessing resources. Has any consideration been given to using Open Policy Agent for this task? https://www.openpolicyagent.org I've actually experimented with using WASM with it for application-level support in other embedded scenarios, and while I didn't quite get it right the first time, the project seems to have excellent community support right now. https://github.com/open-policy-agent/npm-opa-wasm/pull/25#issuecomment-654489286
Also wondering what industry support there might be for UMA vs OAuth.xyz, it sounds like Microsoft is also working on dynamic OAuth 2.0 registration which overlaps with OAuth.xyz? Would it make sense to suggest that despite the odd parts of OpenID Connect and OAuth 2, it's unlikely to go anywhere, and thus UMA or something like it (maybe with different licensing) would "win" in the future? I haven't looked into UMA enough to see how it could be implemented yet with OPA, but I might next...
John Moehrke (Sep 28 2020 at 15:32):
there is a profile of UMA for healthcare use -- See HEART. It is mentioned in the core FHIR spec on the security pages along with many alternative security models.
René Spronk (Jan 08 2021 at 14:29):
Hmm. Would you happen to know of a recorded overview presentation about HEART ? (UMA: https://www.youtube.com/watch?v=0cCXJvJ6GUY )
René Spronk (Jan 11 2021 at 13:58):
FYI: HEART tutorial: https://www.youtube.com/watch?v=8wpYVQDvYJI&feature=youtu.be
Last updated: Apr 12 2022 at 19:14 UTC
