October 18, 2016 Security Conference Call

Back to Security Work Group Main Page

Attendees

x	Member Name		x	Member Name		x	Member Name		x	Member Name
x	John MoehrkeSecurity Co-chair		x	Kathleen ConnorSecurity Co-chair		.	Alexander Mense Security Co-chair		.	Trish WilliamsSecurity Co-chair
x	Mike Davis		x	Suzanne Gonzales-Webb		x	David Staggs		x	Mohammed Jafari
x	Glen Marshall, SRS		.	Beth Pumo		.	Ioana Singureanu		.	Rob Horn
x	Diana Proud-Madruga		.	Serafina Versaggi		.	Joe Lamy		.	Galen Mulrooney
.	Duane DeCouteau		.	Chris Clark		.	Johnathan Coleman		.	Aaron Seib
.	Ken Salyards		.	Christopher D Brown TX		.	Gary Dickinson		.	Dave Silver
x	Rick Grow		.	William Kinsley		.	Paul Knapp		.	Mayada Abdulmannan
.	Kamalini Vaidya		.	Bill Kleinebecker		x	Christopher Shawn		.	Grahame Grieve
.	Oliver Lawless		.	Ken Rubin		.	Paul Petronelli , Mobile Health		.	Russell McDonell

Back to Security Main Page

Agenda DRAFT

1. (2 min) Roll Call, Agenda Approval
2. (5 min) Approve Security WG October 11, 2016 call minutes and Security WG September 13, 2016 Minutes.
3. (15 min) PSAF Ballot v.next Mike to discuss proposed NIB submission by 10-31. See below for details.
4. (5 min) John recommended that the Security WG consider FHIR discussion about two very different role models for Practitioner, which have a Security impact. Please read and react so that we can help with the decision. Practitioner.Role vs PractitionerRole blog by Brian Postlethwaite. See Notes below.
5. (5 min) PASS Audit Conceptual Model – Diana
6. (5 min) FHIR AuditEvent and Provenance ballot comments & FHIR Security Call reminder - John

FHIR Security Ballot comment and CP review and FHIM modeling of PSAF - See agenda at FHIR Security Agenda

Proposed PSAF/TF4FA January NIB

• Security WG proposed PSAF/TF4FA January NIB

Description

• HL7 Security Work Group is continuing development of an overarching Privacy and Security Framework Architecture[PSAF] based on foundational authorization standards: ISO/IEC 10181-3; Information Technology – Open Systems Interconnection – Security Frameworks for Open Systems: Access Control Framework and ISO/TS 22600 Privilege Management and Access Control (PMAC). PSAF builds on the HL7 Composite Security and Privacy Domain Analysis Model as the unifying framework for all of HL7 Privacy and Security standards, and now includes a policy-based Trust Framework for Federated Authorization [TF4FA].
• PSAF/TF4FA conceptual information and behavioral model is intended to align with the approach taken in the draft NIST Internal Report (NISTIR) 8149: Developing Trust Frameworks to Support Identity Federation [NISTR 8149] for federated identities but for federated authorization. The September 2016 ballot version of TF4FA includes a high-level conceptual information model, which represents the privacy, security, and trust policies within each domain that is party to a Trust Framework contract. In this ballot document, the focal Trust Framework contract is an agreement among policy domains on federated authorization policies.
• The January 2017 ballot version includes a Security Label Service with Trust Access Control Decision Information (ADI) behavioral model collaboration model diagram from the HL7 Security Labeling Service specification HL7 Version 3 Standard: Privacy, Access and Security Services; Security Labeling Service, Release 1 (SLS) to specify the use of (1) discoverable encoded Trust Policies for run-time negotiation of a Trust Framework among parties considering exchange of information or valuables; and (2) discoverable verification of a party's capability to support required trust parameters such as levels of assurance, active trust certification status, support for privacy, security, provenance, and integrity policies, and trust technologies.

Revisions from September 2016 Ballot

• Revisions after September 2016 ballot reconciliation include clarification that this model is about the federation of policy domains regarding negotiated trust framework for cross domain authorization. Additions include behavioral model extending the PASS HL7 Security labeling Service to include determination of participation in a trust framework with shared approach to federated authorization and claims verification.

Notes on Practitioner.Role vs PractitionerRole Resource

• Brian and John point out security consequences of Practitioner.Role: "Security cannot easily filter some roles from the record for privacy reasons."
• Brian argues for the PractitionerRole Resource rather Practitioner.Role, because the latter won't scale if we wish to record provider affiliations over time because every Practitioner request would need to return all of this history, and it would bloat the result.