Difference between revisions of "March 2nd, 2010 Security Conference Call"
Finaversaggi (talk | contribs) |
Finaversaggi (talk | contribs) |
||
(5 intermediate revisions by 2 users not shown) | |||
Line 13: | Line 13: | ||
* [mailto:john.moehrke@med.ge.com John Moehrke] Security Co-chair | * [mailto:john.moehrke@med.ge.com John Moehrke] Security Co-chair | ||
* [mailto:milan.petkovic@phillips.com Milan Petkovic] | * [mailto:milan.petkovic@phillips.com Milan Petkovic] | ||
− | * [mailto:ppyette@perimind.com | + | * [mailto:ppyette@perimind.com Pat Pyette] |
* [mailto:ioana.singureanu@gmail.com Ioana Singureanu] | * [mailto:ioana.singureanu@gmail.com Ioana Singureanu] | ||
* [mailto:serafina@eversolve.com Serafina Versaggi] scribe | * [mailto:serafina@eversolve.com Serafina Versaggi] scribe | ||
Line 26: | Line 26: | ||
==Announcements== | ==Announcements== | ||
− | [http://gforge.hl7.org/gf/download/docmanfileversion/5507/6988/HarmonizedPrivacyandSecurityDomainAnalysisModel.ppsx An update to the Harmonized Security Domain Analysis Model presentation] has been posted on GForge in the Doc section under the Security Domain Analysis (DAM)Project folder | + | [http://gforge.hl7.org/gf/download/docmanfileversion/5507/6988/HarmonizedPrivacyandSecurityDomainAnalysisModel.ppsx An update to the Harmonized Security Domain Analysis Model presentation] has been posted on GForge in the Doc section under the Security Domain Analysis (DAM) Project folder |
*Update to this presentation includes: | *Update to this presentation includes: | ||
**Added analysis for Use Case S.4 Negotiate Privacy Policy | **Added analysis for Use Case S.4 Negotiate Privacy Policy | ||
Line 35: | Line 35: | ||
***Sequence diagram shows the final step of the negotiation (consenter has the choice to accept the outcome of the negotiation or to reject it, in which case, nothing is done | ***Sequence diagram shows the final step of the negotiation (consenter has the choice to accept the outcome of the negotiation or to reject it, in which case, nothing is done | ||
**The Related Information and Associations slides show the information related to the Negotiate Privacy Policy use case and the relationships between the classes to arrive at the Information Model | **The Related Information and Associations slides show the information related to the Negotiate Privacy Policy use case and the relationships between the classes to arrive at the Information Model | ||
− | **The model has NOT been changed – | + | **The model has NOT been changed – the additional slides describe the analysis flow from the business use cases to the technical use cases, sequence diagrams and information model. |
==Minutes== | ==Minutes== | ||
===1. Action Items=== | ===1. Action Items=== | ||
− | *'''Team: | + | *'''Team: ''Please submit peer review comments to the Harmonized Security Domain Analysis Model by COB March 4, 2010''''' |
− | ===2. Resolutions- None=== | + | ===2. Resolutions - None=== |
===3. Updates/Discussion=== | ===3. Updates/Discussion=== | ||
====Harmonized Privacy and Security DAM Peer Review==== | ====Harmonized Privacy and Security DAM Peer Review==== | ||
− | The group agreed to use today's meeting to address some questions and comments related to the Negotiate Privacy Policy use case (S.4) even though | + | The group agreed to use today's meeting to address some questions and comments related to the Negotiate Privacy Policy use case (S.4) even though a number of members were absent today (due to HIMSS and RSA) and Co-chair John Moehrke was unable to join call until 1:25 PM EST. We will repeat the presentation and discussion next week. The following summarizes today's comments: |
#The operations described in the Negotiate Policies sequence diagram are not defined in the draft Harmonized DAM. These operations were defined in the original Security DAM and will be included in the next draft revision | #The operations described in the Negotiate Policies sequence diagram are not defined in the draft Harmonized DAM. These operations were defined in the original Security DAM and will be included in the next draft revision | ||
#It was felt that the sequence diagram does not make it clear whether it is describing the Negotiate Privacy Policy use case (which is a manual process) or the Automated Policy Resolution use case S.3 | #It was felt that the sequence diagram does not make it clear whether it is describing the Negotiate Privacy Policy use case (which is a manual process) or the Automated Policy Resolution use case S.3 |
Latest revision as of 18:44, 4 March 2010
Contents
Security Work Group Weekly Conference Call
Meeting Information
Attendees
- Tabitha Albertson
- Bernd Blobel Security Co-chair, absent
- Jim Buckner
- Steven Connolly
- Mike Davis Security Co-chair, absent
- Suzanne Gonzales-Webb CBCC Co-chair, absent
- Rob Horn
- Don Jorgenson
- John Moehrke Security Co-chair
- Milan Petkovic
- Pat Pyette
- Ioana Singureanu
- Serafina Versaggi scribe
- Craig Winter
Agenda
- (05 min) Roll Call, Approve Minutes Feb 23rd, 2010 & Call for Additional Agenda Items
- (40 min) Harmonized Privacy and Security DAM Peer Review
- Negotiate Policies Use Case - deep dive
ACTIVE PROJECTS
- (15 min) Security and Privacy Ontology project
Announcements
An update to the Harmonized Security Domain Analysis Model presentation has been posted on GForge in the Doc section under the Security Domain Analysis (DAM) Project folder
- Update to this presentation includes:
- Added analysis for Use Case S.4 Negotiate Privacy Policy
- Slides were added at the end of the presentation
- They show how the use case relates to technical implementation of the Access Control System (ACS)
- The elaboration shows how to automate the use case – as there needs to be a way for the consenter to submit privacy preferences that could be adjudicated by the ACS in an automated fashion since the use case is a set of manual steps
- The elaboration assumes that the work for the use case is performed by automated systems
- Sequence diagram shows the final step of the negotiation (consenter has the choice to accept the outcome of the negotiation or to reject it, in which case, nothing is done
- The Related Information and Associations slides show the information related to the Negotiate Privacy Policy use case and the relationships between the classes to arrive at the Information Model
- The model has NOT been changed – the additional slides describe the analysis flow from the business use cases to the technical use cases, sequence diagrams and information model.
- Added analysis for Use Case S.4 Negotiate Privacy Policy
Minutes
1. Action Items
- Team: Please submit peer review comments to the Harmonized Security Domain Analysis Model by COB March 4, 2010
2. Resolutions - None
3. Updates/Discussion
Harmonized Privacy and Security DAM Peer Review
The group agreed to use today's meeting to address some questions and comments related to the Negotiate Privacy Policy use case (S.4) even though a number of members were absent today (due to HIMSS and RSA) and Co-chair John Moehrke was unable to join call until 1:25 PM EST. We will repeat the presentation and discussion next week. The following summarizes today's comments:
- The operations described in the Negotiate Policies sequence diagram are not defined in the draft Harmonized DAM. These operations were defined in the original Security DAM and will be included in the next draft revision
- It was felt that the sequence diagram does not make it clear whether it is describing the Negotiate Privacy Policy use case (which is a manual process) or the Automated Policy Resolution use case S.3
- The sequence diagram is intended to describe an automated version of the manual workflow described in the S.4 use case. The manual process is out of scope for this project and the purpose of this effort is to focus on those aspects which can be made interoperable
- The operation submitPrivacyPreference actually includes two steps: (1) a request from the consenter for a blank privacy references form, (2) the consenter submits their privacy preferences. For the purpose of simplicity in the diagram, these two steps are compressed and represented as a single action
- The parameters included in the operations indicate these operations are of a structured (not unstructured-manual) type
- It is unclear whether the PHR conceptual system used by the consenter to submit their privacy preferences is in the same or a different domain from the Access Control System
- The focus of the negotiation process is around consent directives that are derived from existing policies that could be modified (slightly) by an organization (i.e., the organization constrains jurisdictional policy)
- The point of this use case is to describe the situation where the consenter presents privacy preferences that are outside the organization’s policy
- The intent of the sequence diagram is to depict the two possible outcomes:
- where the consenter’s privacy preferences do not conflict with organizational/jurisdictional policies (legally binding policy is returned from the ACS) and the Consent Directive is added to the Consent Directive Management System (within the organization’s domain) and
- where there is disagreement between the consenter’s expressed privacy preferences and the organizational/jurisdictional policies in which case there is no legally binding policy created based on the consenter’s preferences and a Consent Directive is not added to the organization’ Consent Directive Management System
- It was pointed out that it is NOT the function of an ACS to return a policy. An ACS evaluate requests for protected resources. This puts a new requirement on an Access Control System, so it was suggested that the actors within this sequence diagram may need to be adjusted
- The intent of the form is to represent an example of the way in which a consenter can express the privacy preferences that may or may not be allowed by the privacy policy against which the preferences are evaluated
- As soon as a conflict between the consenter's privacy preferences and the default privacy policy is detected, a manual negotiation process must be invoked – the automated process can only proceed when there is an agreement between preferences and existing policies
- There is a question as to whether sufficient encoding exists to detect conflicts between expressed privacy preferences and existing organizational/jurisdictional policies. This requires knowing the encoding of the policies
- To detect conflicts, there must be a standards-based way to encode policies, which John argues is not yet available
- The concept of negotiation is something that was only raised by HITSP last year when many assumed that negotiation was in scope while others within felt that negotiation was always human behavior, not computer-behavior. At that time, the Security WG decided to take a stab at analyzing this concept. As we continue to delve further into this analysis, we may have to revisit the use cases to further clarify Negotiation
The group is encouraged to submit their questions and comments on the Peer Review form by March 4th
Motion made by Pat Pyette to adjourn the meeting at 11:00; seconded by Steve Connolly
No significant decisions or motions were made