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

June 29th, 2010 Security Conference Call

From HL7Wiki
Revision as of 22:19, 6 July 2010 by Finaversaggi (talk | contribs) (→‎3. Updates/Discussion)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Security Working Group Meeting

Back to Security Main Page

Attendees

Agenda

  1. (05 min) Roll Call, Call for additional agenda items & Accept Agenda
  2. (55 min) Composite Security & Privacy DAM Ballot Reconciliation - twenty-two comments beginning at item #55.
    • This is the latest version of the spreadsheet as of 6/22 with last week's votes. To download current version of the spreadsheet, click File/Save Page As and add .xls or xlsx extension

Minutes

1. Action Items - none

2. Resolutions

Vote was taken on comments reviewed to date. Three comments are remaining, and we will complete ballot reconciliation on the next Security WG call, Tuesday, 7/6 

   * 4 Approve, 0 Object, 0 Abstain

3. Updates/Discussion

Ballot reconciliation resumed on remaining comments to the Composite Security and Privacy Domain Analysis Model

Item #56: Unclear why a policy includes the reason the policy is revoked

  • Original disposition: Pending input from other Work Group; updated to Persuasive with Mod
  • John: The illustrative attributes in the classes seem to come from the HL7 V2 Consent message which is a functional model which says that the message is returned to the consent requester indicating that the consent sent was rejected for a particular reason. Here, we are doing data modeling, which is not a functional view
  • Serafina: reasonCode supports revocation of a Consent. This may include the case where a client updates their Consent Directive which was sent to a Consent Directive Management System (CDMS) in order to correct an error in the published Consent Directive. The DAM includes reference to conceptual systems and use cases (in section 3) and reasonCode is there to support certain scenarios of the revokeConsentDirectives operation
  • Pat: The DAM is at the conceptual level – business concepts. The need for a reasonCode might be an environmental constraint in an actual implementation but at the conceptual level, we probably don’t need to think about this. There is no argument that certain implementations might need this attribute but it isn’t needed here.
  • John: I recommended that reasonCode be removed from the DAM (because I don’t understand why it’s in here). Two ways to go; (A) – agree that it doesn’t belong or (B) – explain why it’s in there.
  • Disposition Comment: We will explain why the reasonCode is necessary or appropriate attribute with the DAM. This supports the Rio meeting disposition which was to “Reject, as the “Reason Code” is needed.

Items #57 & 58: PublishedConsent & PublishedPrivacyPolicy

  • Pat: if the only time the URI is populated is when a status code is equal to Published, then it makes sense to have this as a specialized class
  • John believes there are state changes and do not require specializations of their respective classes.
    • Less documentation is better than causing reader confusion. This appears to represent something new and exciting when it is really only a state change.
  • Pat also questioned whether we want to have the public location of the document known or embedded in the document. It is the registry’s job to tell authorized consumers where that location is. If you change the repository, of you change the URI, you have to change the document.
  • Disposition was changed from “Considered - No action required” to “Persuasive with Mod”. Disposition Comment: explain why PublishedConsent is a specialized class as opposed to a state change. Since there is nothing in the use cases that relates to Publishing a policy; either get rid of the attribute or include a use case to support it.

Item #61: purpose:

  • John: The DAM indicates there are different instances of the policy class for each individual purpose. E.g., my privacy policy for treatment is “X”, but my privacy policy for research is “y” – they are different purposes. This is the first place where privacy policies deviate greatly. How do I represent this in the DAM? There would need to be an instance for treatment and an instance for research. That concept becomes less clear as you have top-level vectors like purpose of use that are in conflict with each other. I think this is work at a level below the domain analysis model where the combinatorics of policy is explained. I can see a policy that says Dr. Bob cannot see my treatment data, but Dr. Bob can see my research data. How would I express this, as Dr. Bob is a primary vector as is POU? I know Dr. Bob is the researcher, and if he sees my treatment data he’ll make a linkage between treatment and research and things will be mucked up. There are a few top-level attributes of a privacy policy and the combinatoirics are not obvious from a flat data model.
  • Pat: My take is that purpose doesn’t belong in the privacy rule, that it belongs in the policy. That’s the way it was modeled in the original Privacy DAM. Something has changed between the original Privacy DAM and this composite Security and Privacy DAM.
    • PrivacyPolicy should be an instance of a BasicPolicy. The model diagram doesn’t show where PrivacyPolicy extends from or is a specialization of. Is PrivacyPolicy related to any other policy. There appears to be a relationship (Composition) to Authority.

Item #62: obligationCode

  • John questioned whether the narrative will be changed to explain the difference between ObligationCode (an enumeration), ObligationPolicy (a class) and obligationCode (a coded attribute of a policy or a consent) since the distinction is not clear.
  • The comment may reflect the need to include a narrative section in the front of the document to clarify the UML notation (e.g., to distinguish between a coded attribute and an enumeration)

Item #65: allowedSensitivity

  • John’s comment: Role points at Permissions, a Role does not point to allowedSensitivity. A Permission might point at an allowedSensitivity. This is not consistent with HL7 V2 or V3. We definitely have to include sensitivity in privacy policies.
  • Pat: The two Roles are different (SecurityRole versus Role). The Role is in relation to a provider organization, so it is potentially a clinical role (the way HL7 normally thinks about Roles as opposed to Security roles). The question is, do we mark Roles with particular sensitivities? Do we say, this particular role is only allowed to see things with this confidentialityCode?
  • John: Security folks will say, you cannot do this directly. You may be able to do this indirectly through some permission, but it would be a named permission which enables a sensitivity classification, not a direct attribute of a Role.
  • Pat: If we’re deciding whether or not to include an attribute, get rid of it, because at the level of a DAM it becomes a distraction.

Items #67 & 68: Role

  • Based on the dispositions (Rio and Ioana’s) there is the need to review the decisions we’ve made with respect to roles (SecurityRole and Role – functional and structural roles)

Item #69: AuthorizationPolicy

  • We will clarify the definitions for the different specializations of Policy from ISO 22600 (PMAC). What makes an AuthorizationPolicy different from a RefrainPolicy, etc.

Item #70: levelOfAssurance

  • John: The way this attribute is being used is not clear in the DAM. The definition of the attribute does not explain that within AuthorizationPolicy, the levelOfAssurance exists to specify the (minimum) level required to grant access.
  • Pat: My concern is that LOA would be used for policy selection, but if it is not used for policy selection, then maybe it goes on one of the clauses of policy, but it is not appropriate where it is. Level of Assurance is normally associated with an Identity (a user). If the policy says, this is only applicable to users with LOA = 4, but I’m not sure that we’ve ever seen this in practice. Normally a policy is based on the user and the protected resource.
  • John: I expected to see levelOfAssurance in Privacy policies, or around an operational environment in which users have different ways to access the system, some of them being a low-assurance way (web browser interface) versus a highly secured way (dedicated hardware and smart card to authenticate). Being strongly authenticated (to the same identity) might give you more access than you would have had weakly authenticated to the same identity (e.g., digital signatures which require a smart card). Not sure how this relates to a PrivacyPolicy but that’s more of what I expect to find in a security Policy use of LOA versus a provisioning side of Level of Assurance. Also I didn’t find use cases that required including this attribute in the DAM. Another way to resolve this comment is to remove levelOfAssurance.

Item #71: Security Use Case Analysis and Privacy Use Case Analysis

  • John: I expected analysis of these use cases to be limited to what can be learned from a data modeling perspective, not to include SOA analysis.
  • We will clarify that sections 2 & 3 are Illustrative, not Normative

Item #72: Figure 2.3 – Policy Life Cycle and Figure 3.3 Consent Directive Life Cycle

  • John: If these can be removed, all the better since they create confusion as is.
  • Pat: We need to clarify why these life cycles are different (from each other as well as from HL7 object lifecycle) and we need to include discussion within the DAM around lifecycle. We can refer to the PASS Access Control artifact if desired.

Motion made to accept the dispositions for the items reviewed today by Pat, seconded by Suzanne.

  • Vote: 4/0/0
  • Items #61, 62 & 65 (no vote) as well as 67 & 68 (voted today) will be reviewed next week when Ioana can join the call

Meeting was adjourned at 2:35 PM EDT

Back to Security Main Page

Retrieved from "https://wiki.hl7.org/w/index.php?title=June_29th,_2010_Security_Conference_Call&oldid=38926"