This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

August 5, 2014 Security WG Conference Call

From HL7Wiki
Jump to navigation Jump to search

Meeting Information

Back to Security Main Page

Attendees

x Member Name x Member Name x Member Name x Member Name
x Mike DavisSecurity Co-chair . John MoehrkeSecurity Co-chair . Trish WilliamsSecurity Co-chair . Bernd BlobelSecurity Co-chair
. Chris Clark . Johnathan ColemanCBCC Co-Chair x Kathleen Connor . Duane DeCouteau
. Reed Gelzer X Suzanne Gonzales-WebbCBCC Co-chair x Rick Grow x David Henkel
. Mohammed Jafari . Don Jorgenson x Alexander Mense . Amanda Nash
. Paul PetronelliMobile Health Security Co-chair x Diana Proud-Madruga . Harry Rhodes . Aaron Seib
. Ioana Singureanu . Walter Suarez . Tony Weida . Paul PetronellimHealth Co-chair
. Julia Chan . Steve Hufnagel . Gary Dickinson . .


Back to Security Main Page

Agenda

  1. (05 min) Roll Call, July 29 Meeting Minutes
  2. (10 min) Vocabulary Alignment PSS Deliverables
  3. (10 min) FHIR Proposal on User/Group management See SCIM and IETF SCIM Tracker
  4. Security as co-sponsor for DPROV - Kathleen or Mike
  5. (10 min) FHIR disposition - review/discussion, ongoing agenda item
  6. (05 min) Other business, action items, and adjournment

Back to Security Main Page

==Meeting Minutes== DRAFT

Approval of Agenda (Johnathan/Mike) Approval of July 29 Meeting Minutes

  • Minutes approved: Mike/Diana

Vocabulary Alignment PSS Deliverables - Diana

  • Attendees at today's EHR Interoperability WG meeting were fine with the updates made by Security WG last week.
    • They looked into the definition of a DAM and determined that they'd like to produce a DAM as one of the deliverables.
    • They also refined the risk statement and some of the rest of the PSS document.
  • Diana has sent out the final draft version of the PSS to both the EHR Interoperability WG and Security WG mailing lists.
    • The EHR WG will do a final approval vote at its meeting next week; the expectation is that it will go through with no problems.
    • No other questions or comments were presented on the PSS.

Security WG as co-sponsor of FHIR DPROV - Johnathan

  • S&I is developing a Data Provenance CDA IG based on existing HL7 artifacts.
  • Plan is to move forward with Security WG as a co-sponsor. CBCC has agreed to move forward with this plan and has voted in favor of this collaboration. CBCC is the sponsor.
  • Question from John: How are you going to get this going operationally with three work groups? How will these three outspoken WGs harmonize?

Johnathan's answer: We’ve been cross-posting the various working meetings that we’ve been doing within CBCC to Structured Docs and more broadly across the board. John, your point is very well-taken. If we can get Security involved now, we still have time to make sure that Security is listed as a co-sponsor on the ballot document. It will be our opportunity to get any additions or updates from Security on it. There is no requirement to formally vote on the ballot artifacts, but it’s a good idea to get on the ballot document.

Mike's answer: I think that the Security WG has expressed interest in this from the beginning. We have expertise in it. Just from that perspective, can the Security WG make a meaningful contribution to this effort? I think the answer is “Yes.” It’s totally fitting that we be a co-sponsor.

Kathleen's answer: The Security WG has been very strong in efforts to develop this, and security issues have been addressed all along. We just didn’t have our name on the PSS because it was anticipated that once DESD had given their blessing, Security would be on there.

MOTION PASSED Made by Mike, seconded by Johnathan. Concurrence achieved in favor of Security being a co-sponsor on the DPROV project Objections = none; Abstentions = none

FHIR Proposal on User/Group management See SCIM and IETF SCIM Tracker

John: At the face-to-face meeting, Graham discussed with us that he’s been approached about a user and group resource within FHIR so that we can do management using the same functionality with the same FHIR RESTful resources. He started to prototype those resources, including the implementers of FHIR. He got a lot of people saying there is an ASTM standard that’s based on the LDAP basic schema for user and group. When he compared what those resources contained, they were identical to what he had invented. He reached out to other people saying it’s duplicative, and since FHIR is specific to healthcare, we shouldn’t be reinventing the wheel. He reached out to me and said, "Can you bring this back to the Security WG as a proposal to change what we were intending to do and say 'rather than create user and group management resources, to add to a section of the Security page - or maybe a page off of it - a discussion of user and group management use cases and how to use the FCIM specification to accomplish that if the organization really wants to use a RESTful resource, where you'd make sure that the reader of the FHIR spec understands that user and group management is a state not really specific to healthcare.'"

  • John has included links to the SCIM specification - DRAFT IETF, still under development. There seems to be good uptake of it in the IAM community.
  • Mike would like to see an overview PPT on this specification, maybe from someone in the SCIM working group.
    • He also asked if anyone from the Security WG would like to attend the SCIM working group and assist/influence the path of the specification draft.
  • Discussion to continue next week...

FHIR Dispositions

  • John announced that there was one open FHIR action item, No. 3310 - adding additional notes to the RESTful API about security.
    • He said it’s just a matter of return codes that need some additional text written up. I
    • John will draft something and accept responsibility to work on this item.
  • Kathleen discussed a few of the dispositions with Paul Knapp and produced a PPT that she presented to the Security WG.
    • Purpose of presentation: To review the privacy and security implications of how FHIR Security Labels are implemented. Consider privacy leakage when Security Labels are in the clear in the HTTP Header or in the Atom Feed.
    • Questions: “What’s the technical requirement/benefit for this? To avoid having to look in the payload for access control?"
  • Discussion to continue next week...

Meeting Adjourned at 1505 PDT

Additional minutes provided by --Rgrow (talk) 20:29, 7 August 2014 (UTC)