FHIR Chat · Balloting SMARTv2 · Security and Privacy

In the run-up to balloting SMARTv2, we're looking at issues from SMARTv1 that we resolved as "considered for future use". We did this analysis a couple of months back as part of the Argo2020 project, and discussed with @John Moehrke and @k connor on a call, but I wanted to check here to make sure we're on the same page. Here's a summary of the four topics from SMARTv1 that we marked as "consdiered for future use", and the current plan for each:

Representing EHR "Tenant" as a launch context parameter -- One of our 2017 ballot comments requested the addition of a launch context parameter documenting the sub-org or "tenant" within a health system to which an app launch should be attributed. Our 2017 discussion couldn't get to consensus on how to represent the "EHR tenant" concept; but CDS Hooks has since added a very similar parameter to the hook invocation, which we can borrow. FHIR-31424 proposes adding "tenant" in SMARTv2.
- Plan: add launch context param in SMARTv2.
Additional guidance on dynamic registration -- One of our 2017 ballot comments requested additional guidance on dynamic client registration. Today, much fo this work happening outside of SMART (e.g., in UDAP), such that we wouldn't want to tackle this in parallel.
- Plan: do not address in SMARTv2.
Security and Privacy considerations -- One of our 2017 ballot comments requested the addition of a "security and privacy considerations" section. If the Security workgroup woud like to propose language for a new section in time for a May 2021 ballot, I think that could be a valuable addition. This is also work that could be taken up during ballot reconciliation, so I wouldn't suggest delaying the ballot for this content given that relevant details are distributed through the specification today. Kathleen noted that there's some content in FHI core that we could link to, developed by John. She was going to discuss with the security workgroup.
- Plan: add language if available prior to ballot, or consider adding during reconciliation; do not delay ballot for this.
Client CapabilityStatement -- One of our 2017 ballot comments suggested documenting practices for creation of Client CapabilityStatements in addition to Server CapabilityStatements. I don't think this hasn't come up as a real-world deployment need since 2017, but Kathleen noted there is work underway on a similar topic in the FHIR DS4P IG, so we wouldn't propose to add new content at this time
- Plan: do not address in SMARTv2.

Josh Mandel (Mar 07 2021 at 21:59):

Wanted to check in her particularly about the plan for "security and privacy considerations" section.

John Moehrke (Mar 08 2021 at 13:34):

I don't have any guidance on any of these. They are all things that the consensus group would be the appropriate forum. Even the Security and Privacy Considerations section, where the Security WG recommends that all specifications have a section where the consensus group can document various topics and residual risks that they consensus group discussed. This section is not something that the security wg can fill out for you, this is a section intended to hold information that the consensus group would like to tell the development or deployment security and privacy experts.

Brett Marquard (Mar 08 2021 at 14:44):

This section is not something that the security wg can fill out for you,

I agree, we can't expect security to just 'write-it'. It's incredibly helpful though if someone submits a comment to help form the initial proposal or outline -- they may have already thought about it more.

John Moehrke (Mar 08 2021 at 15:01):

what jira ticket? OAuth has a few "Best Current Practice" specifications for security, simply listing that would be a good start.

Brett Marquard (Mar 08 2021 at 15:19):

oh, I assumed this was a prior tracker...

John Moehrke (Mar 08 2021 at 17:24):

security and privacy considerations should also point at the security labels page in FHIR core for explanation of vocabulary available and common uses for filtered queries.

Josh Mandel (Mar 08 2021 at 20:22):

Thanks @John Moehrke. I've drafted https://github.com/HL7/smart-app-launch/pull/339 to re-group existing security and privacy practices under a common heading ("Security and Privacy Considerations") as well as adding to that a set of references to:

IETF's "Best Current Practices" guide on OAuth 2.0
Core FHIR spec's security.html page

Last updated: Apr 12 2022 at 19:14 UTC

Main menu