March 15, 2011 Security Conference Call

Security Working Group Meeting

• Meeting Information

Back to Security Main Page

Attendees

• Mike Davis Security Co-chair
• Jon Farmer
• Suzanne Gonzales-Webb CBCC Co-chair

• Michelle Johnston
• [mailto: Jim Kretz)
• Tony Weida
• Craig Winter

Back to Security Main Page

Agenda and Minutes

1. (05 min) Roll Call, (Approve Minutes - March 8 in progress, not completed) & Accept Agenda
2. (15 min) Review updates to the draft Security and Privacy Ontology document Note: Earlier version has been removed - Tony Weida

Per the DMAG group updates have been added. (see p.8)

In the document a note has been added that the fist sub ontology is intended to become normative in the future. While this is prepared as an informative ballot the information is normative (Note is a statement of direction for the ballot document)

Diagram: two class hierarchy as they appear in OWL. (figure 2) assertive class hierarchy (as they were authorized (on the right is organized by inferences made by the OWL reasoner—so by example (There is a long flat list of permissions according to the asserted versions that are hierarchical not shown here)

Hierarchy on left is the assertive class hierarchy that’s the way the protégé hierarchy describes it—this is not the way that the OWL logic describes it. ; Assertion is used for occasion when making statements about individuals. i.e. individual organizations; but do not make assertions in OWL about an entire class of organizations (this is a linguistic point that will not concern most readers)

(showing) Object Property in securityandprivacy.owl 7.2.3 This is an inferred hierarchy and is also an inferred object hierarchy in OWL.

• Section on class in the securityandprivacy.owl ontology; added descriptive material fully and partially described classes. (Tony will need people to take a look at and comment) if you’ve looked at previous drafts circulated, the remainder of classes contains sections/subsections…corresponding to the class hierarchy, there is a placeholder for textual definitions as well as entries for the logical definitions of the class as well as a place for explanatory notes.

A separate word document was circulated with material intended to be textual definitions for these classes—I’m hoping to discuss that later in this call. There will be future maintenance on this document—or maybe done in parallel to be done by Tony so that we have a separate word document up to date as we have had significant problems with the definitions in the way they have been developed so afar .

A key part for the RBAC representation are operations, I added a note that all the direct/indirect names subclasses of operate are exclusively intended to be the way they are in the RBAC permission catalog found in HL7. There is a fairly substantial hierarchy; so far I have been organizing them in a separate document. text definitions would be placed appropriately into the same format. The operations do exhibit a hierarchy in the ontology which they do not in the current RBAC permission catalog. The logical definitions which have been drafted for these have to partially characterize they both as a way of clarify retention and motivation the particular hierarchy…this has receive significant discussion in the past and I wanted to acknowledge that here.

• 7.2.4.6 following up on permissions; about the permission categories and specific permissions from HL7 RBAC permission catalog are currently in Securityandprivacy.owl. In order to demonstrate access control decision making I’ve included cover axioms concerning permissions and their subclasses; this tells the OWL reasoner that these are the things we want to recognize; ruling out other permissions. That’s something that is appropriate in example ontology. But as a general purpose resource I imagine that other people who use the ontology will want the option to have their own permissions as well if they want to extent the permission catalo—we should et things up that facilitates that (for the future)

• Also, acknowledge that incurrent limitations section; the glossary of terms is a start. We can add more; we need reviewers to point those out.

• The introduction to the way the logical descriptions of the classes are presented; are separated out in appendix B. The people from Spain requested a more healthcare specific example. Even though this is an example to illustrate different OWL constructs as opposed to being part of the ontology. I’ve changed the sample class to say :SamplePhysician. It fits more nicely for a document that is healthcare IT. Also added is a paragraph which talks about class expression in OWL. It’s typically used in the ontology to describe a super class in a name class. Such as permission or an organization we can logically describe some of the properties that are used for security and privacy but it’s not a complete definition that a human has in mind when describing permission. This is a paragraph which tries to explain a general example of how it works in description logic.

That covers what I wanted to say specifically in the document--talking about the definitions including the comments submitted by Spain. [No questions, moved to next agenda item]

1. (15 min) Review proposed Revised Text descriptions of Classes - Tony Weida

(showing - List of many o the higher levels of classes)

First column is the list higher level classes in securityandprivacy.owl with indentation to reflect the hierarchical organization.

Second column; current draft of the descriptions of these classes (I’ve made progress but I hope people will help some improvements)

Next column has description material from the previous document circulated previous –in some cases I’ve made up the wording for the ontology and most cases I took them from one of the sources we’ve talked about including the ANSI RBAC specification as well as the security and privacy DAM and RBAC permission catalog and some case are explanatory notes in the last column

Goals set: for drafting these descriptions. It’s not an easy thing as there are competing roles in some cases. Tony has tried to come up with clear/crisp and preferably brief Pictionary-like descriptions for these classes with the idea is to get the basic definition right, then we would consider adding more explanatory iterations. Tony has tried to give the descriptions a consistent form—so as to not to get caught up on how the descriptions differ from one another and not get hung up on how the sentence is structure. So the current format is a blank is a blank for example access is an application of an operation to an object Often when a class is a specialization of a more general class to introduce its specialization on by saying a blank is a blank where the second blank is the class that is been specialized followed by how it differs. This is a traditional way of setting out definitions of classes.

Other goals are to come up with descriptions that are consistent with the other sources we are referencing wherever possible. In many cases I’ve tried to substantially reproduce the wording. The wording for constraint in the current draft description is similar to the ANSI RBAC description but I’ve tried to be careful in singular class names. Gain consistency of description---but there is competing goals wherein I want to be consistent with sources as well as the standards. As you look through the descriptions and see variations these are some of the potential variations. We (the group) will need to decide how to improve these descriptions. in a word document like this and in the draft document we were looking at before I like to use italics in the word being it used in the decision on the other hand I want to have the descriptions be the same OWL ontology that reports on it. Unfortunately protégé doesn’t support mark-up like italics within OWL ontologies. And there are complications on how they appear when you put quotation marks around them—so for now I am using simple sentences.

• Some of the tradeoffs I’ve made – some of the current limitations—are in the same order as they were circulated.

RecordObject – from HL7 RBAC; adapted from SNOMED CT, so far I’ve just copied most of it from into the current version. This is an example of a much longer and elaborate description in other cases…it does start off with a declarative sentence The record is an entity…

Operate – (a definition we have struggled with) I wanted to use the verb form of the word ‘operate’ to work with the specific operations that are under the heading other verb-type in its group—record, read create append, etc. there is a relationship that there is sense the root of the hierarchy has the same form as the things underneath so that there is a relation… on the other hand that since this is a verb to reflect that differently by starting with “to” ‘to operate…’ reflecting the definition as described in the HL7 RBAC permission catalog

Organization – here was not crisp clear of definition of organization so I referred to Merriam Webster definition used – an organization is an administrative and/or functional structure. I suspect this is adequate for the ontology—but any input is welcome

Jurisdictional organization – this is a case of what I mentioned earlier that I wanted to introduce the term being described and talk about the more general class that it specialized in the ontology. And to describe how it specializes it as territorial authority. The wording is slightly different it fundamentally I believe it captures wording and intent as in the security and privacy DAM.

Policy – description from an ISO specification. I chose to reflect that in the current draft for the ontology as well.

PrivacyRule – (as found in the Security and Privacy DAM) tried to clarify definition by saying; a privacy rule specifies permission or obligation to treat information in accordance with privacy wishes **INPUT would be appreciated*

Functional role – cut down on much of the reference material of the external definitions; using: this is a more crisp description. a functional role is a security role that conveys a set of permissions intended to enable performance of identified tasks. ** (CHECK vs. Neumann Strembeck)

this is the material that I wanted to cover on the contextual material here. ~end Tony

Suzanne (question) --is there a reference or mention of the Neumann Strembeck paper here? Since we are referencing RBAC we should still be referencing their paper.

Tony --it’s possible to reference possible reference such as Neumann and Strembeck. I don’t recall if I put that as a reference but I can put a note to add that well.

Mike – seems to be that we should be citing the documents/standard/etc if they exist…rather than writing the definitions as we go. Is that a fair comment?

Tony – yes, that’s a fair comment. it’s one thing that the ontology itself would be a self- contained resource, so that people look at the logical definitions they can understand partly the content based on the name of the class. To have concise textual definitions helps people to check whether the ontology to know the ontology is thinking of the class name the same way as they are also a basis of logical definition. At the same time its reasonable place to reference other various standards. The annotations in the ontology which annotate reference material in all the classes. Presently its sources to be the HL7 DAM. Was that a satisfactory response?

Mike – is the sourcing explicit in the model…meaning that the DAM itself has a reference itself to the source--is the reference explicitly or is something that we have to infer?

Tony One of the annotations on the right is the source annotation which names the source HL7 composite security and privacy dam. In principle that could be a url, or add the url at some point. Short answer is yes. It references the source in the ontology.

Mike – okay, we just have to track it back to see what I says, if you’ve provided the definitions and the definitions are in the DAM we should find it there…it should also be defined in the DAM

Tony – part of the review process will confirming that, so I will be going over all of that again.

Mike – I don’t know the best way to approach that we repeat a definition in the document that may change. We’d have to maintain the link hoping that things don’t change or something like that.

Tony – I’d describe the link as a reference source and the primary goal that the text definition inside the ontology be consistent with the class name and the logical definition of that class. Although it’s valuable to cite external sources for authority and for future information ultimately the reference standard will be untlamate reference in a compatible way. One way around that is to elaborate the source the reference with a version or source dat.

Jon – the underlying point is if that source may change we have to point out that the resource is taken from this point of the writing. The most important thing in the document is understandability. If it’s not easy enough for them to find a definitions. If you can point to a specific thing rather that just pointing to the DAM document is a risky thing.

Tony – as I mentioned in an earlier e-mail to Ioana. Some of the source descriptive material is better suited to the ontology. In some cases of the DAM there can be lengthily prose about a class whatever calling out a dictionary definition.

Mike – that might be a failing of the DAM… which might be alleviated by creating a glossary in the DAM.

Tony - its part of the mechanist conveying to the readers the intention of what these things are. The DAM of course may get balloted at intervals so it’ll be snap shots of the ontology and snapshots of the DAM,

Mike – it seems like there are…the terminology is important if you are going to make an effort to define things. You have to point to a standard that represents the concept for which you are talking about or you reference the DAM. Or you write your own if all else fails. if there is an authoritative source that meets your definitions—we should be talking about those things…that’s an issue here.

Tony – okay.

1. (15 min) DMAG comments to the “HL7 SECURITY AND PRIVACY ONTOLOGY – MAY 2011 INFORMATIVE BALLOT”, 2011/03/14

In a previous call, DMAG (Spain) was going to supply a description of the work on aligning the MVCO standards with the privacy ontology. As it turns out they wrote several pages worth and proposed putting it in the specification between the current limitations and the future directions sections. It seems to me that the two sections are very closely related so I hesitate to break them up. What I’ve done prior to the submission was to put a placeholder for it. Although alignment with other standards in the scope state, there was interest in pursuing it. My sense is that material would logically belong in an appendix to this document,--assuming we are going to put it in. I request the input from the group… I did have some feedback on the text that was provided, such as the corrections of the privacy and security ontology to have these class names and relationships consistent with the ontology. I haven’t heard back about that yet, but I imagine that they would be agreeable about making those changes. Otherwise my plans are to continue about what I’ve talked about, and get the next draft out to the list for review by late tonight. And I would give opportunity to take a look and provide feedback over the next week.

DECISION Place pages from DMAG (Spain) comments in the document Appendix so as not to lose context, meaning from the MVCO standards and our ontology. A placeholder was made in the document however since the DMAG response was larger than a few paragraphs this was deemed the best solution.

1. Action Item: An inquiry about aligning the ontology with SAIF was sent to Galen Mulrooney, (It has been mentioned on past Security-CBCC calls as a likely source of information). Status: Awaiting response from Galen.

Tony will follow up.  If there are any other suggestions about the paragraph in particular please defer to Tony. 

1. Action Item: A paragraph was presented at the March 8th Security-CBCC meeting; comments were requested from the group but to date we have received none. So, a couple questions:I believe that the ideal of the security and privacy ontology is well aligned in principle with a service-aware interoperability framework. Services can take advantage of the ontology to intraoperative, but I’m not aware that the HL7 SAIF says anything specific how you should create or use ontologies, so I’m not able to detail how it specifically aligns with practice.

1. Does the draft paragraph match your understanding? 
2. Should I ask other people for input, and if so, who? 

Jon – SAIF comes out about the OMG focus where you organize a whole body of enterprise perspective. If you’re going to build web services, the computation is very important because that’s where the operations show up. Where the ontology connects to SAIF is the elegance where the computational view of SAIF interfaces; if all those operations line up with our ontology operations, then you could deploy some web services that are specified by SAIF specs and you could use ontology compliant mechanisms to enforce privacy because the operations line of with our operations. From the perspective of an implementer, If they implement SAIF specs then they are in great position to use our ontology for privacy enforcement. Tony – everything is good in principle, I’d be interested to know where the ontology doesn’t line with principles (if there are any)

1. (5 min) Other Business - Request for Agenda Items for HL7 Working Group Meeting - May 2011, Orlando, Florida

Meeting adjourned: 0 9:58AM EST

Back to Security Main Page