Security+and+Privacy+Workgroup+Meetings

toc =2010 Meeting Minutes and Agenda=



2010-12-27 T-con
Agenda: > Roll – 1 min > Review backlog and progress since last meeting – 5 mins > Goals >> Address ONC S&I Framework Reference Implementation and Testing Team issues >> Review initial version of Auth Framework in new template > Updates/Announcements – 5 mins > Reference Implementation team issues > Testing Team issues > New AF spec updates > > Round table – >> Any new topics? > Recap plan for next week – 1 min
 * Amram Ewoo
 * Benson Chang
 * - Chuck Hagen
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * David Roberts
 * Deborah Harris
 * George Varghese
 * - Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * John Moehrke
 * - Kanwarpreet Sethi
 * Karen Witting
 * Laure Tull
 * Les Westberg
 * Marty Prahl
 * - Michael Nenashev
 * Neelie Bajaj
 * Sandy Stuart
 * Scott Robertson
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin
 * Errata template
 * Broken Wiki links

Meeting notes:

Next call will be next MONDAY, at the same time as the existing scheduled IEPD call (11:00 AM Eastern time), due to the upcoming federal holidays.

No Testing Team members on call.

The RI team has some outstanding issues as per the drop box.

There wasn't a quorum on the call, but we continued the meeting as a non-decisional call largely focused on Q&A for the RI team. Specifically, we reviewed and updated the FAQ dropbox issues brought forth by the RI team.



2010-12-17 T-con
Agenda: > Roll – 1 min > Review backlog and progress since last meeting – 5 mins > Goals >> Address ONC S&I Framework Reference Implementation and Testing Team issues >> Review initial version of Auth Framework in new template > Updates/Announcements – 5 mins > Reference Implementation team issues > Testing Team issues > New AF spec updates > > Round table – >> Any new topics? > Recap plan for next week – 1 min
 * - Amram Ewoo
 * - Benson Chang
 * - Chuck Hagen
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * David Roberts
 * Deborah Harris
 * - George Varghese
 * Jeff Tunkel
 * - Joe Lamy
 * John Donnelly
 * John Moehrke
 * - Kanwarpreet Sethi
 * Karen Witting
 * Laure Tull
 * - Les Westberg
 * Marty Prahl
 * - Michael Nenashev
 * Neelie Bajaj
 * Sandy Stuart
 * - Scott Robertson
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin
 * Feedback on having a "newbie call"
 * Errata to spec
 * Editorial guidelines
 * Will the wiki be maintained

Meeting notes:

__New Participants Call__

Eric H. suggests creating a NHIN E "new participant" call periodically. The purpose of the call would be to have a few long standing NHIN E participants and Subject Matter Experts (SME) available for open discussions to provide a more approachable method of participating in the NHIN E. Scott R. newbie call is a good idea. Benson C.: they are mapping use cases to specs. Probably good content for a new participants area of the wiki. Their mapping takes the form of a swim lane diagram. Benson will investigate sharing and doing an informal demo. Joe L. is setting up a testing wiki with common errors, like setting up certs. Pulled in ops team tips too. Designed to help new participants as well. Joe will send a link to this testing team wiki content. Overall broad support for this concept, now needs to be vetted at higher levels in the NHIN E. Benson will add this to the agenda for the next All Hands call.

__Errata Page Proposal__

Eric H. suggested starting to create errata pages for each NHIN E specifications. Each spec would have a link to this new dedicated permanent Wiki page. This would be an extension of the existing NHIN E FAQ drop box process. The errata page would be the authoritative source of content approved by the Spec Factory for incorporate into the next quarterly release of the associated specification. It would serve a (hopefully) valuable purpose in that it would give readers the ability to go to a single place for pending updates to specs, whereas, currently, readers have to go to multiple places in this wiki AND it is currently difficult to determine what is approved vs. pending. Today's workgroup indicated that they felt an errata page for each spec would be a valuable addition to our process. Benson will add this to the agenda for the next All Hands call to discuss with the overall group.

__Blocking Issues__

Joe L. no blocking issues now. Michael N. no blocking issues now.

__Normative vs. Non-Normative Content__

Decision needed: How do we distinguish, normative vs non-normative text? Currently, we mix the two in our specifications in most cases, without clearly distinguishing the two. The can lead to problems where a reader will mistakenly take non-normative content and use it as normative. One approach could be to have a pattern where we consistently place normative text followed by non-normative text. In this case, each section would be tagged as being normative or non-normative. Do we have an overall major section in the document, one for normative, and one for non-normative text. Les suggests putting in something like in examples to make them more normative in nature. Perhaps we can have a textual description of what sections of the example should be revised. Scott: Put a "rule" in the document of which has precedence (example vs. text). Also advise the reader to contact the authoring team to clarify ambiguity so we can address and clarify the specifications if/as needed.

Working Decision: As a pattern, we'll try to put normative content first, and then immediately followed by non-normative content, both tagged appropriately, and in the same section. Larger examples can be placed in an appendix.

__New Authorization Framework Specification__

For the underlying specifications column of the specs, list key underlying standards. Also perhaps list which parts of the spec are useful. Put a list of the "scope of the adoption" for the underlying specifications, such as, for example, indicate that we are not adopting the SAML Identity Provider services. The purpose is to tell implementations what they can ignore or read.

__Announcements__

Next call will be next MONDAY, at the same time as the existing scheduled IEPD call (11:00 AM Eastern time), due to the upcoming federal holidays.



2010-12-10 T-con
Agenda: > Roll – 1 min > Review backlog and progress since last meeting – 5 mins > Goals >> Coordinating announcements >> Address ONC RI team issues >> Address blocking issue from ONC S&I Testing team > Updates/Announcements – 5 mins > RI team issues > New AF spec updates > Round table – >> Any new topics? > Recap plan for next week – 1 min
 * - Les Westberg
 * - Tom Davidson
 * David Colins
 * Allen Hobbs
 * - Chuck Hagen
 * George Varghese
 * Neelie Bajaj
 * - Amram Ewoo
 * Steven Cason
 * Dan Vigano
 * - David Morris
 * Dave Colbert
 * - Benson Chang
 * Wendy Laposata
 * Jeff Tunkel
 * Laure Tull
 * Deborah Harris
 * David Roberts
 * George Varghese
 * - Amram Ewoo
 * - Sandy Stuart
 * - Scott Robertson
 * John Donnelly
 * - Joe Lamy
 * Marty Prahl
 * - John Moehrke
 * Michael Nenashev
 * Karen Witting
 * - Kanwarpreet Sethi
 * - Eric Heflin

Meeting notes:

This meeting was largely devoted to working on the FAQ drop box. A number of issues were brought forth by the RI and Test Teams. Edits were done directly on that page and will be incorporated into the FAQ as the issue resolutions are finalized.

It was decided to try to meet for the rest of the year. We will use Monday's IEPD call to address the two new blocking issues for the Testing Team related to the use of PatientID values. We will need to schedule new meeting days, though, since our current Friday meetings fall on dates that many participants will be unavailable.



2010-12-03 T-con
Agenda: > Roll – 1 min > Review backlog and progress since last meeting – 5 mins > Goals >> Coordinating announcements >> Address ONC RI team issues >> Address blocking issue from ONC S&I Testing team > Updates/Announcements – 5 mins > RI team issues > Confidentiality Code change status > Port assignment change status > PurposeOfUse change status >  Blocking issue and UUID blocking issue > New AF spec updates > Round table – >> Any new topics? > Recap plan for next week – 1 min
 * - Les Westberg
 * - Tom Davidson
 * - David Colins
 * - Allen Hobbs
 * - Chuck Hagen
 * - George Varghese
 * - Neelie Bajaj
 * - Amram Ewoo
 * - Steven Cason
 * - Dan Vigano
 * - David Morris
 * - Dave Colbert
 * - Benson Chang
 * Wendy Laposata
 * - Jeff Tunkel
 * Laure Tull
 * - Deborah Harris
 * - Benson Chang
 * David Roberts
 * George Varghese
 * Amram Ewoo
 * - Sandy Stuart
 * Scott Robertson
 * John Donnelly
 * - Joe Lamy
 * Marty Prahl
 * John Moehrke
 * - Michael Nenashev
 * - Karen Witting
 * - Kanwarpreet Sethi
 * - Eric Heflin
 * Call for working session meeting to put AF spec in new format

Meeting notes:

No NTC meeting in Dec. Jan call is still being scheduled. The NTC met last month and approved all four pending specs. Moving to the Coordinating Committee for final approval as a next step.

Announced that the confidentiality code draft text has received no objections from the Spec Factory. Next step to integrate it into the specifications.

Announced that an OCHIN call was scheduled for today. Invited all participants to attend. Topics will be the identified confirmed defect where the CONNECT SAML AssertionID value uses a UUID that often (randomly) violates the schema, and the issue whereby which CONNECT is not generated a nested SAML  which is expected by the OCHIN implementation. **UPDATE**: The call occurred today, and one vendor team is going to determine the effort of modifying their product to accommodate accepting the UUID AssertionID as currently being generated by CONNECT, and the potential  element change. In parallel, Eric H is going to continue to pursue obtaining an authoritative resolution to the  issue from the OASIS SAML Technical team. Both issues are being addressed with a priority on maintaining compatibility with the current installed base of CONNECT deployments, even if CONNECT is know to be flawed, to allow sufficient time for the UUID issue to be correct in such a way that interoperability is not compromised. If CONNECT was fixed immediately, the OCHIN would still not be able to interoperate with others using CONNECT since many CONNECT installs will take many months to take a version or even a patch upgrade. But the UUID defect will be submitted to the CONNECT team for resolution as part of their normal release process.

The  attribute inside an  has been advanced to the SAML OASIS group for an authoritative resolution. A call has been set up today to get the affected stakeholders in a dialog to try to identify a pragmatic approach for moving forward. Tom suggested asking what vendor test suites are testing for in this regard.

Call for feedback on the port assignment text. Will it work for all? Tom and Eric need to reach out to all of the federal agencies to request feedback. No feedback received yet.

Review the TLS text (copied below) for inclusion in the updated AF and CAQH Core II Advanced Connectivity Rule. Note: Insufficient time to review this on the call today, so ejh posted it to the group via email.

The RI MP questions document was reviewed in detail today and most issues were resolved. ejh will post the issues to the FAQ and will post the document on this page later today. Most of today's call was devoted to RI questions.

“Normative: Organizations utilizing this specification MUST employ an x.509 mutually authenticated secure channel using a FIPS- approved implementation of SSL or TLS. Organizations MUST use a NIST-validated cryptographic module for encryption of data on this channel and MUST use a FIPS-approved key exchange method. This secure channel MUST be operating in FIPS-approved mode as per [] or its successor document.
 * Proposed TLS Text:**

Non-normative: This list, which is actively maintained by the NIST as of this writing, is the authoritative source of which products, modules, and modes are approved for use by the NIST for Federal Information Processing. This list, or its successor, should be periodically reviewed for updated information as part of each organizations' internal best practices. Since security is a very dynamic area of the industry, we anticipate that the FIPS guidelines will change while this specification is still in effect and implementers are cautioned to create their implementations in such a way that the version of SSL and or TLS, and it’s associated configuration, can be changed to reflect updated NIST / FIPS security requirements and best practices.”

The below text was approved as part of AF 2.0.1 by the NTC.

Non-normative implementation note: CAUTION: As of September, 2010, the NHIN Exchange has become aware of a potentially breaking change related to the SAML PurposeOfUse AttributeValue. As can be observed in the immediately prior non-normative example, the example text is incorrect and inconsistent with the remaining text in this document. Specifically, the example text “PurposeForUse” should have been “PurposeOfUse”. The PurposeForUse attribute has unfortunately been widely implemented by NHIN Exchange members. When, and if, the NHIN Exchange elects to correct this error, the NHIN Exchange change management process will be employed. This will provide a transparent decision making and upgrade process with a suitable transition period. The NHIN Exchange’s Security and Privacy Workgroup has elected to temporarily leave the errant text as is, and to call implementer’s attention to this discrepancy, via this implementation note, so they can plan accordingly. For more detailed and more recent information on this topic, please see the NHIN Exchange’s Wiki page at: http://standards-and-interoperabilty-specifications.wikispaces.com/Auth+PurposeOfUse+Research or the main Security and Privacy Workgroup page at: http://standards-and-interoperabilty-specifications.wikispaces.com/Security+and+Privacy+Team.
 * Proposed PurposeOfUse Specification Text:**

Still seeking feedback on the below text from the federal partners:

Normative: In the absence of NHIN policy to the contrary, NHIN Exchange members MUST support at least one of the specified Internet TCP/IP port numbers for all NHIN Exchange inbound connections. NHIN Exchange Members MUST support all three specified port numbers for NHIN Exchange outbound connections. The specified port numbers are port 443 (designated as the "primary port"), port 4437 (designated as the "secondary port"), and port 14430 (designated as the "tertiary port").
 * Proposed Port Assignment Text:**

Non-normative: The IANA has been asked to register NHIN Exchange specific port numbers, but has not accommodated the request as of this writing. The secondary and tertiary ports listed in the above paragraph were selected due to their apparent availability. Specifically, no known official or unofficial use of these ports is known at this time from either legitimate applications, or from security threats. More detailed, and potentially more up-to-date, information on this topic may be found on the the NHIN Exchange Wiki at http://standards-and-interoperabilty-specifications.wikispaces.com/Port+Assignment.



2010-11-19 T-con
Proposed Agenda: > Roll – 1 min > Review backlog and progress since last meeting – 5 mins > Goals >> Coordinating announcements (to keep the group informed and in sync >> Address blocking issue from ONC S&I Testing team > Updates/Announcements – 5 mins >  Blocking issue > New AF spec updates > Review the new taxonomies > Round table – >> Any new topics? > Recap plan for next week – 1 min
 * -Les Westberg
 * -Tom Davidson
 * -David Morris
 * -Benson Chang
 * Wendy Laposata
 * Jeff Tunkel
 * -Ed Monjay
 * Laure Tull
 * David Roberts
 * George Varghese
 * Amram Ewoo
 * Sandy Stuart
 * Scott Robertson
 * John Donnelly
 * -Chuck Hagen
 * -Joe Lamy
 * Marty P (SSA)
 * John Moehrke
 * -Eric Heflin
 * NIST call today
 * Call for working session meeting to put AF spec in new format

Meeting notes:

Announced that the confidentiality code draft text has received no objections from the Sec and Privacy WG, so it's been advanced to the entire Spec Factory for comments and objections.

We reviewed the newest version of the Authorization Framework work done by Amram (and others). Overall we reached conditional approval to move forward subject to a few changes (better internal docs, single page for all attributes, and clarification of the meanings of a few columns). We expect to circulate a new version of the template today.

Joe L indicated the presence of a blocking issue related to the absence of a  attribute inside an  element, as documented in the FAQ. We issued a preliminary determination that the  attribute was only allowed at a higher level and not at this level in the XML document. Eric H. and Tom D. to research.

We reviewed the draft port assignment text and decided it was sufficient as a working draft, subject to feedback from stakeholders, esp. the affected federal agencies. Next steps: Eric H. is to put the draft text in an email and circulate it to the known impacted agencies for feedback. Once feedback has been received, or a reasonable amount of time elapses, the draft text will be advanced to the Sec Priv workgroup via email.

The NIST email exchange between Eric H. and Matthew Scholl regarding TLS and esMD issues. We decided that the best course of action was to set up a telephone conference with the NIST to explore the issues (documented in this Wiki).

We reviewed the below list of changes to the next version of the Auth Framework and agreed to publish this list on a new Wiki page devoted to this topic. We also agreed to begin having breakout AF authoring sessions with the goal of publishing a new draft for the NTC to consider by Dec 27th.

From prior meeting: //Authorization Framework Backlog// Namespace issue, string element values, perhaps specify a type attribute to constrain the element value better Baseline crypto family policy Enhance the description of each attribute in an expanded Excel file Have a glossary reference Document each attribute better Incorporate FAQ into specification Correct PurposeForUse vs. PurposeOfUse subjectConfirmation types clarifications Computable artifacts (WSDLs, XSDs, WS-SecurityPolicy, etc.) Bring the spec into the new template Implementation guide (SAML use for the NHIN)



2010-11-12 T-con **no call today**
Proposed Agenda: > Roll – 1 min > Review backlog and progress since last meeting – 5 mins > Goals >> Coordinating announcements (to keep the group informed and in sync) >> Approve new Authorization Framework Specification Template for circulation to the entire Spec Factory >> Address blocking issue from ONC S&I Testing team >> Update specs with new Confidentiality Code draft text > Backlog grooming - 5 mins > Updates/Announcements – 5 mins >> Confidentiality code draft text >> NIEM packaging meeting reminder and invitation >> Timelines: NTC meeting 4th Monday of each month > IANA port issue - 10 mins > NHIN / esMD TLS version spec clarifications working session – 10 mins > Update list of Authorization Frameworks changes and move to new Wiki page- 10 mins > Initial discussion of new x.509 cert issue (should we accept that into our backlog)? - 10 mins > Round table – >> Any new topics? > Recap plan for next week – 1 min
 * Tom Davidson
 * David Morris
 * Wendy Laposata
 * Jeff Tunkel
 * Ed Monjay
 * Laure Tull
 * David Roberts
 * George Varghese
 * Amram Ewoo
 * Sandy Stuart
 * Scott Robertson
 * John Donnelly
 * Chuck Hagen
 * Joe Lamy
 * Marty P (SSA)
 * John Moehrke
 * Eric Heflin

Meeting notes:

Announced that the confidentiality code draft text has received no objections from the Sec and Privacy WG, so it's been advanced to the entire Spec Factory for comments and objections.

We reviewed the newest version of the Authorization Framework work done by Amram (and others). Overall we reached conditional approval to move forward subject to a few changes (better internal docs, single page for all attributes, and clarification of the meanings of a few columns). We expect to circulate a new version of the template today.

Joe L indicated the presence of a blocking issue related to the absence of a  attribute inside an  element, as documented in the FAQ. We issued a preliminary determination that the  attribute was only allowed at a higher level and not at this level in the XML document. Eric H. and Tom D. to research.

We reviewed the draft port assignment text and decided it was sufficient as a working draft, subject to feedback from stakeholders, esp. the affected federal agencies. Next steps: Eric H. is to put the draft text in an email and circulate it to the known impacted agencies for feedback. Once feedback has been received, or a reasonable amount of time elapses, the draft text will be advanced to the Sec Priv workgroup via email.

The NIST email exchange between Eric H. and Matthew Scholl regarding TLS and esMD issues. We decided that the best course of action was to set up a telephone conference with the NIST to explore the issues (documented in this Wiki).

We reviewed the below list of changes to the next version of the Auth Framework and agreed to publish this list on a new Wiki page devoted to this topic. We also agreed to begin having breakout AF authoring sessions with the goal of publishing a new draft for the NTC to consider by Dec 27th.

From prior meeting: //Authorization Framework Backlog// Namespace issue, string element values, perhaps specify a type attribute to constrain the element value better Baseline crypto family policy Enhance the description of each attribute in an expanded Excel file Have a glossary reference Document each attribute better Incorporate FAQ into specification Correct PurposeForUse vs. PurposeOfUse subjectConfirmation types clarifications Computable artifacts (WSDLs, XSDs, WS-SecurityPolicy, etc.) Bring the spec into the new template Implementation guide (SAML use for the NHIN)



2010-11-05 T-con
Proposed Agenda: > Roll – 1 min > Review backlog and progress since last meeting – 5 mins > Goals >> Coordinating announcements (to keep the group informed and in sync) >> Approve new Authorization Framework Specification Template for circulation to the entire Spec Factory >> Agree on two new ports for NHIN use and create draft text >> Determine NIST specific questions >> Update list of Authorization Framework potential updates > Backlog grooming - 5 mins > Updates/Announcements – 5 mins >> Confidentiality code draft text >> NIEM packaging meeting reminder and invitation >> Determine if there are any blocking issues for other teams >> Timelines: NTC meeting 4th Monday of each month > Review of updated AF template - 10 mins > IANA port issue - 10 mins > NHIN / esMD TLS version spec clarifications working session – 10 mins > Update list of Authorization Frameworks changes and move to new Wiki page- 10 mins > Initial discussion of new x.509 cert issue (should we accept that into our backlog)? - 10 mins > Round table – >> Any new topics? > Recap plan for next week – 1 min
 * - Tom Davidson
 * - David Morris
 * Wendy Laposata
 * Jeff Tunkel
 * - Ed Monjay
 * Laure Tull
 * David Roberts
 * - George Varghese
 * - Amram Ewoo
 * Sandy Stuart
 * Scott Robertson
 * John Donnelly
 * Chuck Hagen
 * - Joe Lamy
 * - Marty P (SSA)
 * John Moehrke
 * - Eric Heflin
 * Added new x.509 cert issue

Meeting notes:

Announced that the confidentiality code draft text has received no objections from the Sec and Privacy WG, so it's been advanced to the entire Spec Factory for comments and objections.

We reviewed the newest version of the Authorization Framework work done by Amram (and others). Overall we reached conditional approval to move forward subject to a few changes (better internal docs, single page for all attributes, and clarification of the meanings of a few columns). We expect to circulate a new version of the template today.

Joe L indicated the presence of a blocking issue related to the absence of a  attribute inside an  element, as documented in the FAQ. We issued a preliminary determination that the  attribute was only allowed at a higher level and not at this level in the XML document. Eric H. and Tom D. to research.

We reviewed the draft port assignment text and decided it was sufficient as a working draft, subject to feedback from stakeholders, esp. the affected federal agencies. Next steps: Eric H. is to put the draft text in an email and circulate it to the known impacted agencies for feedback. Once feedback has been received, or a reasonable amount of time elapses, the draft text will be advanced to the Sec Priv workgroup via email.

The NIST email exchange between Eric H. and Matthew Scholl regarding TLS and esMD issues. We decided that the best course of action was to set up a telephone conference with the NIST to explore the issues (documented in this Wiki).

We reviewed the below list of changes to the next version of the Auth Framework and agreed to publish this list on a new Wiki page devoted to this topic. We also agreed to begin having breakout AF authoring sessions with the goal of publishing a new draft for the NTC to consider by Dec 27th.

From prior meeting: //Authorization Framework Backlog// Namespace issue, string element values, perhaps specify a type attribute to constrain the element value better Baseline crypto family policy Enhance the description of each attribute in an expanded Excel file Have a glossary reference Document each attribute better Incorporate FAQ into specification Correct PurposeForUse vs. PurposeOfUse subjectConfirmation types clarifications Computable artifacts (WSDLs, XSDs, WS-SecurityPolicy, etc.) Bring the spec into the new template Implementation guide (SAML use for the NHIN)



2010-10-29 T-con
Agenda: > Roll – 1 min > Review backlog and progress since last meeting – 5 mins > Goals >> Coordinating announcements (to keep the group informed and in sync) - Done >> Get approval or change list on new Authorization Framework Specification Template - Done >> Determine next steps for port assignment issue - Done >> Finish draft confidentiality code text - Done >> Determine NIST specific questions >> Create list of Authorization Framework potential updates - Done > Backlog grooming - 10 mins > Updates/Announcements – 5 mins >> NIEM packaging meeting reminder and invitation – 1 min >> Determine if there are any blocking issues for other teams – 1 min >> Modeling tools demo today > Review of new AF template - 10 mins > IANA port issue - 10 mins > Confidentially code value set text working session – 10-15 mins > NHIN / esMD TLS version spec clarifications working session – 10 mins > Create initial list of Authorization Frameworks changes - 10 mins > Documenting each SAML attribute better - > Review of new AF template > Round table – >> Any new topics? > Recap plan for next week – 1 min
 * Tom Davidson
 * David Morris
 * Wendy Laposata
 * Jeff Tunkel
 * Ed Monjay
 * Laure Tull
 * David Roberts
 * George Varghese
 * Amram Ewoo
 * Sandy Stuart
 * Scott Robertson
 * John Donnelly
 * Chuck Hagen
 * Joe Lamy
 * John Moehrke
 * Eric Heflin

Meeting notes: No blocking issues were brought forth.

No changes to the blacklog were identified.

Amram reviewed the new Authorization Framework template. Generally positive feedback. Models will need to be reviewed prior to inclusion to ensure they are of use to the target audiences. Suggestion: Adding a Warnings section. Table format for attributes was reviewed. Suggestions: Add a hierarchy element, comments, schema, xpath, min/max, others, conditional. Also suggested: was to embed Excel file, with a link with more content. Suggestions: Add reference, schema, wsdl, and glossary links. Also suggested: have a reference to another section be as precise as possible. Decision: Will use a basic table in the Word document and then a link to an Excel file with many additional columns. Volunteers to refactor the existing Authorization Framework into the new format: Tom, Amram, and Eric.

Reviewed IANA port issue. It was suggested that we move forward with a group-selected port. With a fall back plan. Eric will also petition for the IANA to redefine their definition of a service to include a NHIN profile.

//Authorization Framework Backlog// Namespace issue, string element values, perhaps specify a type attribute to constrain the element value better Baseline crypto family policy Enhance the description of each attribute in an expanded Excel file Have a glossary reference Incorporate FAQ into specification Correct PurposeForUse vs. PurposeOfUse subjectConfirmation types clarifications Computable artifacts (WSDLs, XSDs, WS-SecurityPolicy, etc.) Bring the spec into the new template Implementation guide (SAML use for the NHIN)

Timeline: Goal is to publish a new version by end of 2010. Final NTC call date will be obtained and provided by Amram.

Confidentiality code draft text:

Non-normative implementation note: The NHIN Exchange has become aware that this attribute is a somewhat controversial topic and that this value set may be subject to change in the future. Although all value sets are ultimately subject to change, this particular attribute has been identified as one that some organizations are actively seeking to further constrain. We suggest implementers consult the URL wiki for the latest information regarding this topic, background information, and references to the HL7 work group in charge of this value set.



2010-10-22 T-con
Agenda: > Roll – 1 min > Review backlog and progress since last meeting – 5 mins >> Spec refactoring >> Testing team issues >> Confidentiality code >> IANA port issue >> esMD discussions and research > Goals > Backlog grooming - 10 mins > Updates/Announcements – 5 mins >> Several out of band meetings occurred >> NIEM packaging meeting reminder and invitation – 1 min >> Determine if there are any blocking issues for other teams – 1 min >>> Any test team or other production issues – 10 mins > Confidentially code value set text working session – 10-15 mins > NHIN / esMD TLS version spec clarifications working session – 10 mins > Documenting each SAML attribute better - > Review of new AF template > Round table – >> Any new topics? > Recap plan for next week – 1 min
 * Tom Davidson
 * Jeff Peacock
 * Ed Monjay
 * George Varghese
 * Laure Tull
 * David Roberts
 * Joe Lamy
 * Kanwarpreet
 * Serafina Versaggi
 * John Moehrke
 * Eric Heflin
 * Update backlog
 * Updates (to keep the group informed and in sync)
 * Finish draft confidentiality code text
 * Determine NIST questions and determine who would like to be involved with the NIST discussion
 * Get group thoughts and guidance on multiple topics as per the agenda
 * CAQH Core II/II Workgroup
 * NIST
 * esMD

Tom suggests creating additional documentation providing guidance on the various subjectConfirmation issues.

The backlog was reviewed and no objections were raised

Discussed the NIEM package approach (wait for all tools, vs. move forward now). Overall agreement to move forward with the current approach; and keep refining it over time. John M suggests that the tools are not as important as the artifacts' utility (correctness, completeness, accuracy). Esp. since there will be no wire-level changes.

Testing team issue: Discussion: The testing team is seeking guidance on their overall approach for testing SAML assertion attributes. See the below link for the discussion. http://standards-and-interoperabilty-specifications.wikispaces.com/message/view/Testing+Team/28918897 Should they restrict values for attributes such as user names to reasonable values, or should they pass values that seem right? For example, a generic SAML user, that is hard coded, vs. one that is properly constructed. Since some values, such as user ids, are assigned by organization's internal processes, then it would be difficult for the sending organizations to change or configure. Consensus seems to be to advise the test team to only enforce the syntax of the request attributes, and not to try to determine if the internal gateway semantic meaning is implemented properly. Joe suggested that the Spec Factory offer some "test guidance" for attributes. John M offered that the testing ROI would likely be low for complete testing. Jeff P also feels there should be a bar whereby which some items are required by the NHIN, others are below that level and are specific to a given implementation and use of the NHIN. Tom D: Let the testing team handle specific "profiles" or purposes. Perhaps have several levels of testing: 1) for very basic, common denominator NHIN Exchange testing, and 2) for more advanced profile-based testing. Joe is interested in determine if is is viable to test an entire flow. Eric suggested that Joe work with the ONC to restart a Onboarding Testing Workgroup. Scope and charter of the test team: "test to the specs" but this is likely insufficient. Need test sample scripts, sample data, sample users, etc. The test team mandate is difficult currently do the fact that our specs are very flexible right now. Now they test for the capabilities of the "good players", next they are focusing on handling "bad players".

NIST discussion: Tom, John, Pam, Amram, Rich K.

Discussed confidentiality code text: Agreed to move foward with a simple warning for now, and a wiki page documenting the issues, concerns, etc.

2010-10-11 T-con
No meeting this week (Eric is traveling)

2010-10-04 T-con
Agenda: > Roll – 1 min > Review backlog and progress since last meeting – 5 mins >> Spec refactoring >> Testing team issues >> Confidentiality code >> IANA port issue >> esMD discussions and research >> Update backlog (new items, new column) > Updates/Announcements – 5 mins >> Several out of band meetings occurred (CAQH Core II/II Workgroup) >> More help from ONC / Deloitte >> NIEM packaging meeting reminder and invitation – 1 min >> Determine if there are any blocking issues for other teams – 1 min >>> test team or other production issues – 10 mins > Confidentially code value set text working session – 10-15 mins > New topic: NHIN / esMD TLS version spec clarifications working session – 10 mins > Removing SAML for some allowed profiles (such as esMD) – more detailed discussion – 10-20 mins > Documenting each SAML attribute better - > Round table – >> Any new topics? > Recap plan for next week – 1 min

Meeting notes:

__Confidentiality code draft text:__

Non-normative implementation note: The NHIN Exchange has become aware that this is a somewhat controversial topic and that this value set may be subject to change in the future. We suggest implementers consult the URL wiki for the latest information regarding this topic, background information, and references to the HL7 work group in charge of this value set. All value sets are subject to change, but this one in particular is likely to be constrained or chainged.

Perhaps provide guidance on how to avoid the problem. Some partners are using the full value set, so implementers should be aware.

HL7 is the owner of this value set. NHIN Exchange has chosen to adopt this.

The value set we adopted with info by category type. There are value sets that exist. What does CDA point to?

Is this on the agenda for the NHIN Technical and Policy Committee.

__esMD Discussion__

TLS draft text

We expect that the CMS is subject to FIPS 140-2. The CMS has reached out to their internal chief security officer.

FIPS 140-2.

Normative: Organizations utilizing this specification MUST use TLS 1.0, or the latest guidelines as issued by the NIST in their 140-2 publication family. In the event the NIST provides TLS version requirements in a publication other than 140-2, that supersedes 140-2, then that publication's guidance MUST be used instead of FIPS 140-2.

Non-normative: Federal agencies are currently required to comply with the latest security rules issued by the NIST under their FIPS guidelines. Specifically, that for confidential data, federal agencies MUST use TLS 1.0 as per FIPS 140-2. Since security is a very dynamic area of the industry, we anticipate that the FIPS guidelines will change while this specification is still current.

Eric to document some draft with the background and send around to the Sec and Privacy Workgroup for revisions.

SAML optionality discussion: What IS an NHIN transaction? WS-Trust was build-up for the NHIN E, which relies on SAML heavily. While it is possible to carry the SAML-type attributes in other (custom?) attributes. While this may provide short term relief from the SAML requirements, it may not provide a long-term solution and the CMS may indeed find higher value with the SAML attribute. We are seeking alignment in the industry, that would be hurt by lack of SAML. Resh issue: Should the NHIN E make our SAML profile clearer so that that vendor support is easier, bearer vs. holder-of-key.

2010-10-04 T-con
> Proposed Agenda: >> Roll – 1 min >> Review team subworkgroup mandate - Eric/Rich >> Confirmation of the target audience - Eric/Rich/All >> Review of updated models - Ed - Postponed >> Decision on IEPD folder structure - All >> Decision on location of models in package - All >> What artifacts are of interest? >> Need to include a change log esp. for breaking or substantive changes >> Versioning issues >> A suggestion was made to use a Debian like virtual package for overall NHIN >> Change mgmt issues >> Creating documentation content backlog - All >> Documenting each SAML attribute better - Eric >> Roundtable - All >> Recap plan for next week – 1 min > Please see below for meeting notes (post meeting)
 * Ed Monjay
 * Rich Kernan
 * Amram Ewoo
 * Tony Maillia
 * Steven Cason
 * Bob Yencha
 * Nick Vennaro
 * Jeff Tunkel, LM Ref Implementation Lead
 * Joan Judhanine
 * Giang Bui
 * Ositova Tunkel
 * Chuck Hagen
 * Tom Davidson
 * John Donnelly
 * Dave Roberts
 * Model driven specifications (for doc generation)

2010-10-01 T-con
> Agenda: >> Roll – 1 min >> Review backlog and progress since last meeting – 3 mins >> NIEM packaging new meeting time announcement – 1 min >> Confidentially code value set text review - 3 mins >> esMD working session - 30 mins >> ONC test team / SSA discussion regarding two SAML attributes – 10 mins >> Removing SAML entirely - introduction to topic - 10 mins >> Documenting each SAML attribute better - time permitting >> Roundtable – >>> Any new topics? >> Recap plan for next week – 1 min > Please see below for meeting notes (post meeting)
 * Ed Monjay - ONC
 * Jeff Peacock - KP
 * Joe Lamy - ONC/Nitor/Testing
 * Rich Kernan
 * Sarafina Versagi
 * Amram Ewoo
 * Bob Yencha
 * Thomas Davidson
 * Mike Sullivan
 * Eric Heflin
 * esMD discussions and research
 * IANA port issue
 * PurposeForUse vs. PurseOfUse specification changes - 3 mins

Didn't have a quorum Test team issues: 1) WS-Addressing for the SOAP action in the SOAP header: The specs identify the valid actions, 6 are specified currently. The samples were using old versions. The IHE specs have updated. The SOAP fault action was not specified. 2) Also in WS-Addressing, for the messageID element, UUIDs are largely used, but there are 3 flavors. Need clarity. I'm suggesting that the Messaging team address these issues. 3) Discussed a malformed AuthDecisionStatement and reviewed his results. See the page for a more detailed discussion. - Add stronger language that the ACP or IACP attribute should be removed. 4)

2010-09-24 T-con
> Agenda: >> Roll – 1 min >> Intro to two new team members >> Review backlog and progress since last meeting – 3 mins >> CONNECT update (if there is interest) - 10 mins >> PurposeForUse vs. PurseOfUse specification changes - 10 mins >> confidentially code value set introductory discussion - 10 mins >>> John Moehrke to discuss this to determine if we should add this change proposal to our backlog >> Working session on NIEM packaging – 15 mins >>> Ed M, modeling demo (auth framework model-to-artifact generation) - 10 mins >>> >>> >>> >>> >>> Eric H, show sample IEPD package >> ONC test team / SSA discussion regarding two SAML attributes – 10 mins >> Removing SAML entirely >> Documenting each SAML attribute better >> Roundtable – ? mins >>> Any new topics? >> Recap plan for next week – 1 min > Please see below for meeting notes (post meeting)
 * Rich Kernan
 * Chuck Hagan
 * Amram Ewoo
 * Bob Yencha
 * Ed Mojay
 * Thomas Davidson
 * Richard Franke
 * Ken S
 * Eric Heflin

Introduced two new team members Chuck and Amram that will be helping us. Amram will be helping from the Project Mgmt side, and Chuck will be helping from the content and tools side largely.

Eric gave brief update on CONNECT conf.

Testing team and RI team needs to be involved earlier! The final decision (determining if a specification is ready) will be via a process of sign off from various team.

PurposeForUse vs. PurposeOfUse non-normative text was updated in the Authorization Framework and entered the change management process.

Confidentially code topic: Is this value set (and all of its values) to be used. John M has created a blog entry with a suggested subset. At least one organization (IBM) is using the value set today beyond the 4 proposed. HL7 currently "owns" this value set. HL7 does not currently have this on their agenda, to our knowledge, at this time. Current proposed solutions: 1) constrain to the 4 suggested values; 2) not constrain and allow the value set to be reduced, potentially, at the HL7 level. 3) Create non-normative implementation guidance related to this issue (not ideal, may change per HL7 underlying standard, needs to be consistent (resource, policy, SAML attributes)).

Motivation: John M broached this topic largely related to substance abuse confidentiality codes as these codes have more stringent confidentiality requirements than normal clinical data. Not clear how these addition values were brought into the value set. Question: Is this approach sufficient to resolve the problem? What is the right levels for these additional levels of tagging? There is different levels of sensitivity to segments of health data (considering 42CFR2).

This is equivalent to one variable being used for multiple purposes perhaps (overloading). Also, isn't this issue equivalent to us attempting to prevent implementers from making mistakes internally? The policy, the user attributes in the SAML, and the resource attributes must be consistent (CDA or human entered for blobs).

Will we accept this topic into our work group? Proposed approach: We will not accept constraining this into our work group; but we will provide non-normative implementation guidance.

2010-09-17 T-con
> Agenda: >> Roll – 1 min >>> Ed Monjay >>> Wendy Laposata >>> David Roberts >>> Amram Ewoo >>> Jeff Peackock >>> Rich Kernan >>> Bon Yencha >>> John M >>> Laurie Tull >>> Tom Davidson >>> Eric Heflin >> Review backlog and progress since last meeting – 3 mins >> PurposeForUse vs. PurseOfUse - 30 mins >> esMD security discussion – 15 mins >>> Review of their workflow >>> Using same OID for both home community ID and org ID >> Working session on NIEM packaging – 15 mins >>> Ed M, modeling demo (auth framework entity relationship diagram) - 10 mins >>> --- stopped here in today's discussion --- >>> ONC test team / SSA discussion regarding two SAML attributes – 10 mins >> Removing SAML entirely >> Documenting each SAML attribute better >> Roundtable – ? mins >>> Any new topics? >>> Who’s going to the CONNECT conference? >> Recap plan for next week – 1 min > Please see below for meeting notes

PurposeForUse vs. PurposeOfUse issue

During Trial implementations a specific SAML assertion attribute was named "PurposeForUse". It was deprecated and is now called, correctly, PurposeOfUse. During the process of updating the documentation, the non-normative NHIN specification content was not updated, even though the normative text was updated correctly. All known implementers developed their implementations using the incorrect PurposeForUse attribute name. The goal would be to document they way interfaces were built. And then correct the attribute in the future using the NHIN E change management process.

Solution: Correct the text to PurposeOfUse in the specification and in the same place, document that this is currently PurposeForUse in live implementations.

Outstanding issue: What would the impact be of changing this today to PurposeOfUse to implementations today? Is this value being used for access control? Can they look for both attributes?

KP would be able to switch easily and immediately. Medicity would be able to make the switch easily and immediately. VA ? DoD ? SSA no impact to the SSA (but it may impact their partners) CONNECT ?

Next step: Rich K will reach out to the ONC and known implementers to determine the impact and timelines to upgrade.

Update the docs to provide this info and fast track the documentation change.

2010-09-10 T-con
> Agenda: >> Roll – 1 min >>> Sandy Stuart, KP >>> Jeff Peaccock, KP >>> Tom Davidson, SSA >>> Mike Sullivan, Healthlink/Healthbridge >>> Bob Yencha >>> Rachael F?, CAQH >>> Laurie Tull, Anakam >>> Rich Kernan, ONC >>> David C, Healthdata >>> Allen Hobbs, KP >>> Ed Monjay, ONC >>> Lincoln W?, >>> Scott Robertson, >>> John Moehrke, >> Review agenda – 1 min >> Review backlog and progress since last meeting – 3 mins >>> Met with the esMD team >>> Added new esMD guidance Wiki page >>> Created NIEM IEDP Wiki page and rough draft structure >>> Created new Security FAQ Wiki page >>> Discovered SSA / ONC test team issue >> Working session on NIEM packaging – 15 mins >>> Target audiences >>> Proposed dir structures from Eric and from ONC >>> Ed M, modeling demo << stopped here >>> Role and scope of modeling >> esMD security discussion – 15 mins >> ONC test team / SSA discussion regarding two SAML attributes – 10 mins >> Create NHIN Security FAQ page – 5 mins >> Roundtable – ? mins >>> Any new topics? >>> Who’s going to the CONNECT conference? >> Recap plan for next week – 1 min

2010-09-03 T-con
Agenda: Review backlog and new Wiki page (link below)Craig will present a new requestPrioritize the backlog <stopping point during today's call>Consider owners for requestsWorking session on highest priority item Roll: Craig Miller, Rich Kernan, Tom Davidson, Scott Robertson, Laurie Tull, Mike Sullivan, Sandy Stewart, Tony Mallia., Bob Yencha, Allen Hobbs, Dan Vigano, Eric Heflin


 * Topic: esMD / CMS Security Guidance**

New request from CMS esMD Spec Workgroup.

Summary: CMS receives requests for reimbursements. This results in a CMS request for supporting documentation from the providers. Today, this is largely Fax and paper based. The CMS is seeking NHIN support for this workflow.

Proposed (Desired) Workflow: CMS uses a physical letter and wants the NHIN to respond to the request.

Payload: XDR?

Today: They use X12, EDI using delimited text (HL7 2x like?).

CAQH: Has developed specifications for delivering these X12 payloads using web services. CORE Phase II 270 "connectivity rule" defines this. A "claims attachment" X12-275 for the medical evidence would come from providers to justify reimbursement for procedures. They are seeking to use NHIN messaging platform and the CAQH platform to converge. Using SOAP 1.2 over HTTP(S). Using TLS. Outstanding issue: How should the info be encoded, acknowledgement of the submission, and authentication (our work). Section 4.3.2. Using username/password and x.509 certificate over 2-way-SSL.

CAQH is working on Phase III. We have a chance to converge and influence more.

Support the full healthcare administrative transactions.
 * Related issues:**

Cross community provisioning (Holder-of-key) A third party identity provider (or providers)
 * Dependencies:**

Does the CMS trust an end-user? Or do they trust a NHIN end point? Will the CMS stand up a end-user database / identity / user provider now? If they are doing end-user based trust then they will need to stand up one.

The CMS could stand up a SAML identity provider The esMD submission submitter would include sufficient information to allow the CMS (TP-20) to perform an additional user level.
 * Approach**

1) "What" is authenticating? A user or a system? 2) Is relaying a use case? 3) Does this represent a drive for allowing and accommodating end-user authentication.
 * Issues:**

Work with the esMD workgroup on a weekly basis.
 * Request:**

HIH = Health Information Handler
 * Definitions:**

The core rule has two methods for authentication 1) username/password; or 2) x.509 on the channel.

They are using the Username token profile SAML profile. This is not a NHIN approved profile (at this time). The password is encrypted or plain text. (See pg. 36 of the connectivity rule.)

2010-08-20 T-con
Confirmed the above priorities Identified some documentation questions for the NHIN Documentation team Discussed the NIEM process impacts to this (and other) workgroups Refactoring would contain three steps: 1) defining the artifacts; 2) create a new AF specification/implementation guide; 3) packing in IEPD

IEPD 101 and NIEM info from Rich Create a prototype of the structure for the docs, using the Wiki and review with the team next week
 * Team Next steps:**