This wiki has undergone a migration to Confluence found Here

March 13, 2018 PSAF Call

From HL7Wiki
Jump to navigation Jump to search

Back to Security Main Page

Back to PSAF Main Page

Attendees

. Member Name . Member Name . Member Name . Member Name
. John Moehrke Security Co-chair x Kathleen Connor Security Co-chair . Alexander Mense Security Co-chair . Trish Williams Security Co-chair
x Christopher Shawn] Security Co-chair x Suzanne Gonzales-Webb x Mike Davis . David Staggs
. Mohammed Jafari x Beth Pumo . Ioana Singureanu . Rob Horn
x Diana Proud-Madruga x Francsico Jauregui . Joe Lamy . Galen Mulrooney
. Paul Knapp . Grahame Grieve . Johnathan Coleman . Aaron Seib
. Ken Salyards x Jim Kretz . Gary Dickinson x Dave Silver
. Oliver Lawless . [1] . David Tao . Greg Linden

Back to Security Main Page

Back to PSAF Main Page

Agenda

  1. (3 min) Roll Call, Agenda Approval
  2. (5 min) Review and Approval of the March 6th Minutes
  3. (50 min) TF4FA Ballot Work Session - Mike Davis and Chris Shawn

Minutes

  • Chris Chaired
  • Agenda and Minutes were reviewed. Kathleen moved, Mike seconded. 7-0-0.
  • Mike walked through recent changes to Trust Framework for Federated Authorization. We've restructured the TF4FA from one volume with 2 Chapters into two separate volumes. Also working on a third volume for Audit, Provenance, and Blockchain.
  • Ballot document will follow PASS ACS format with a business, information, computational and engineering perspectives. In conformance with RM-ODP, business perspective is converted to enterprise viewpoint. Computational view is deemed out of scope.
  • Initial Policy Diagram model is a high level view of the 4 key classes from ISO TS 22600-2:2006: Policy class specialized into Basic, Meta, and Composite policy. TF4FA will focus on Basic policy class. Meta and Composite
  • Second is the overarching Trust Model with the three types of Authority Domains: Jurisdictional, Organizational, and subject of care. Removed the Venn Diagram from the Federated Domain because the trust contract is no longer considered an integration of policies, but a bridging between two domains where the disclosing domain has the final say on whether the policies in the trust proposal from the requesting domain are acceptable, and executes the contract.
  • Third sequence diagram "Establish Trust Contract Model" illustrates the flow of the trust message between the requesting and disclosing domains. A third Trust Framework actor was added, which controls the policy resolution service, external policy management service, and federated trust contract.
  • Policy Bridging Boundary View Use Cases illustrates the relationships among Access Control Services and Trust Management Services. This is the use case illustrated by sequence diagram, so is not a workflow. It shows that Domain A has capability to send trust proposal to Domain B.
  • Domain B has capability to receive the proposal and to get policies from the Policy Administration Point. B has the capability to send any run time policies and the policies in A's trust proposal to its Policy Resolution Service. Policy Resolution Services has capability to get saved trust policies from an External Policy Management Service.
  • Policy Resolution Service has the capability of bridging input policies to (1) execute a trust contract, which is equivalent to Domain A's trust proposal by counter signing that proposal; or (2) generate an alternative signed trust proposal, which Domain B's ACS sends to Domain A's ACS.
  • Domain A's Policy Resolution Service evaluates against it's PAP and saved policies in External Policy Management Service. If acceptable, Domain A's Policy Resolution Service may sign this proposal to execute a trust contract, which is submitted to Domain B. In the alternative, Domain A's Policy Resolution Service may generate a counter trust proposal, which is sent to Domain B's ACS to continue the process until either party declines to continue or a trust contract is established.
  • Trust Policy Information Model shows the classes from PMAC Basic Policy in focus, showing both the instantiation of Basic Policy as a Privacy or Security Policy. Also enumerates the types of BasicPolicy.authorities as organization, jurisdiction, and subject of care.
  • Access Control related PMAC classes are out of scope because these assume that a Trust Contract is a precondition.
  • Assumption is that the use cases are automated without human interaction.
  • Last model is the new Trust Proposal Message, which becomes the Trust Contract once executed/countersigned by the disclosing Domain. It includes key Basic Policy classes as Access Decision Attributes of the Initiator, which in this case is one of the Domain Authorities - jurisdiction, organization, or subject of care.
  • Checked SAEAF methodology to confirm that the PASS ACS Engineering View doesn't apply to TF4FA. Will change Business to Enterprise View per RN-ODP, but likely will not use the Computational Viewpoint.

Meeting Materials

  • Mike to post a slide deck with the models for consideration as the text will be primarily aimed at articulating the models. TF4FA Model Overview deck