Security+and+Privacy+Workgroup+Meetings+Q4+2011

toc =2011 Q4 Meeting Minutes and Agenda=



**2011-12-16 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke (LM)
 * Andrew Weniger
 * - Benson Chang (Deloitte)
 * Bob Hall
 * Cbaba
 * - Chuck Hagen (Deloitte)
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris (LM)
 * - Dave Arvin (SSA)
 * David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * James Rachin (ONC Test Team)
 * Jeff Tunkel
 * - Jocelyn Dabeau
 * Joe Lamy (Nitor Group)
 * Joan DuHaime
 * John Donnelly
 * John Moehrke (GE)
 * Josh Abraham (SSA)
 * Judith Hutman (Mitre Group)
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting (IBM)
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * - Michael talbot (VA)
 * Mike Levy (SSA
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * - Sandy Stuart (KP)
 * Sanjay
 * Scott Robertson
 * - Seonho Kim
 * Sergei Haramundanis
 * Sourabh Pawar
 * Srinivasa Kukatla
 * - Shrikant Gajengi (SSA)
 * Seravina V
 * Steven Cason
 * - Tom Davidson (SSA)
 * Wendy Laposata
 * - Eric Heflin (THSA)

Agenda:
 * Announcements
 * Policy/Tech WG Test plan approval
 * New NIST 800-63
 * Review CP-SP-001-001
 * Issuer Tec/Policy guidance (issue #170)
 * Guidance for Tec/policy certificate revocation latency issues (issue #171)
 * New topic: Goals for issuance of NwHIN Certificate Policy statement
 * Round table

Goals for CP - Make the cert more precisely defined.


 * __Issue #170__**

Reviewed CP-SP-001-001: Need to have someone research the outstanding issue in the CP` for final objections prior to sending it to the entire NwHIN Exchange Spec Factory. Two changes were identified. 1) we added more background text explaning that the change was partially driven by the need for more testable specifications; and 2) we discussed the potential need to further constrain the spec in terms of the issuer element. Both of these issues were documented in the CP. We took a vote, and no objections were raised towards presenting it to the NwHIN Exchange Spec Factory to give them a one month period of time to submit comments or raise objections (until the first NwHIN Exchange Spec Factory meeting in 2012). If no objections have been raised by then, then CP-SP-001 will be presented to the NwHIN Policy/Technical committee for review.

What fields are required for x.509 v3? Anything? The  and the  are under consideration for Joe's name Joe suggest decoupling his cp-sp-001-001 and perhaps addressing this issue elsewhere


 * __Issue #171__**

We discussed the below text today and decided that more clarity is needed, esp. in terms of common use of "validation". John M and Eric H are to create updated text via email for this group to consider next week.

Topic: x.509 Cert Revocation checking Goal: Create official guidance for the NwHIN Policy/Technical WG to consider and hopefully approve.

Background: Below are draft recommendations regarding cert revocation from this week's NwHIN Policy/Technical WG call.

X.509 Digital Certificate Revocation Policies


 * 1. Verification Frequency**

We will send the following text to the Sec and Priv WG for a 1 week review, and then the Spec Factory for a 1 month review prior to sending to the Policy/Technical Task Group.

Background for the NwHIN Policy/Technical Task Group: The process of validating a certificate is distinct from the process of checking for the revocation status of a certificate. The process of validating a certificate is an internal IT process that determines if a given certificate is within it's validity period, is issued under a trusted trust anchor, is signed properly, is intact, etc. The process of checking for the revoked status of a certificate involves using a trusted external source, such as CRL or and OCSP responder network to determine that a valid certificate has not be suspended or revoked. It is important to understand that a valid certificate can exist in revoked, suspended, or non-revoked status. Similarly a invalid certificate (such as one that has expired) will not be revoked in most cases. Thus is very important that implementors first check for the validity of a certificate before checking its revocation status. It is incorrect to check for the revocation status of a certification until that certificate's validity has been confirmed.

Recommendations:

a) Validation frequency checking: Implementations should check the validity of the reciprocal exchange partner's certificate each transaction.

b) Revocation frequency checking: Implementations should check the revocation status of the reciprocal exchange partner's certificate each transaction.

Issue: The messaging platform specification requires that either a CRL or OCSP be used to check whether a certificate is still valid. The specification does not address how often an Exchange Participant should verify whether a certificate has been revoked.

Recommendation: The messaging platform specification should be revised to reflect the following:

A Participant shall verify certificate validity each time a transaction is established.

Impact: This approach assures that participants verify certificate validity before exchanging data. The benefit of verifying certificate status outweighs potential performance issues.


 * __New Topic NwHIN Certificate Policy (CP)__**

Topic: Should the NwHIN have an official CP?

During the discussion today we decided that from our perspective, the NwHIN Exchange indeed needs to issue a Certification Policy. We also decided to first address higher level objectives such as the need to support multiple CAs, self-governance, and/or Direct/Exchange support.

Goals
 * Need transparency
 * Need to enable self-governance
 * Need to allow for multiple trust anchors / vendors in the future
 * We are current addressing a number of this issues one at a time
 * May be more efficient to address these policy issues in a batch

Talking points
 * As we move towards self-governance this may help us
 * The current CP is vendor-controlled
 * The lack of a CP published by the NwHIN prevents transparency
 * The Direct Project has issued a minimal CP



Federal Bridge CP



**2011-12-02 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke (LM)
 * Andrew Weniger
 * - Benson Chang (Deloitte)
 * Bob Hall
 * Cbaba
 * - Chuck Hagen (Deloitte)
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris (LM)
 * Dave Arvin (SSA)
 * David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * James Rachin (ONC Test Team)
 * Jeff Tunkel
 * - Joe Lamy (Nitor Group)
 * Joan DuHaime
 * John Donnelly
 * - John Moehrke (GE)
 * Josh Abraham (SSA)
 * Judith Hutman (Mitre Group)
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting (IBM)
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * Mike Levy (SSA)
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart (KP)
 * Sanjay
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Sourabh Pawar
 * Srinivasa Kukatla
 * Shrikant Gajengi (SSA)
 * Seravina V
 * Steven Cason
 * - Tom Davidson (SSA)
 * Wendy Laposata
 * - Eric Heflin (THSA)

Agenda:
 * Announcements
 * Review CP-SP-001
 * Issuer Tec/Policy guidance (issue #170)
 * Guidance for Tec/policy certificate revocation latency issues (issue #171)
 * New topic: Initial discussion on issuance of NwHIN Certificate Policy statement
 * Round table


 * __Issue #170__**

Reviewed CP-SP-001 for final objections prior to sending it to the entire NwHIN Exchange Spec Factory. Two changes were identified. 1) we added more background text explaning that the change was partially driven by the need for more testable specifications; and 2) we discussed the potential need to further constrain the spec in terms of the issuer element. Both of these issues were documented in the CP. We took a vote, and no objections were raised towards presenting it to the NwHIN Exchange Spec Factory to give them a one month period of time to submit comments or raise objections (until the first NwHIN Exchange Spec Factory meeting in 2012). If no objections have been raised by then, then CP-SP-001 will be presented to the NwHIN Policy/Technical committee for review.


 * __Issue #171__**

We discussed the below text today and decided that more clarity is needed, esp. in terms of common use of "validation". John M and Eric H are to create updated text via email for this group to consider next week.

Topic: x.509 Cert Revocation checking Goal: Create official guidance for the NwHIN Policy/Technical WG to consider and hopefully approve.

Background: Below are draft recommendations regarding cert revocation from this week's NwHIN Policy/Technical WG call.

X.509 Digital Certificate Revocation Policies


 * 1. Verification Frequency**

We will send the following text to the Sec and Priv WG for a 1 week review, and then the Spec Factory for a 1 month review prior to sending to the Policy/Technical Task Group.

Background for the NwHIN Policy/Technical Task Group: The process of validating a certificate is distinct from the process of checking for the revocation status of a certificate. The process of validating a certificate is an internal IT process that determines if a given certificate is within it's validity period, is issued under a trusted trust anchor, is signed properly, is intact, etc. The process of checking for the revoked status of a certificate involves using a trusted external source, such as CRL or and OCSP responder network to determine that a valid certificate has not be suspended or revoked. It is important to understand that a valid certificate can exist in revoked, suspended, or non-revoked status. Similarly a invalid certificate (such as one that has expired) will not be revoked in most cases. Thus is very important that implementors first check for the validity of a certificate before checking its revocation status. It is incorrect to check for the revocation status of a certification until that certificate's validity has been confirmed.

Recommendations:

a) Validation frequency checking: Implementations should check the validity of the reciprocal exchange partner's certificate each transaction.

b) Revocation frequency checking: Implementations should check the revocation status of the reciprocal exchange partner's certificate each transaction.

Issue: The messaging platform specification requires that either a CRL or OCSP be used to check whether a certificate is still valid. The specification does not address how often an Exchange Participant should verify whether a certificate has been revoked.

Recommendation: The messaging platform specification should be revised to reflect the following:

A Participant shall verify certificate validity each time a transaction is established.

Impact: This approach assures that participants verify certificate validity before exchanging data. The benefit of verifying certificate status outweighs potential performance issues.


 * __New Topic NwHIN Certificate Policy (CP)__**

Topic: Should the NwHIN have an official CP?

During the discussion today we decided that from our perspective, the NwHIN Exchange indeed needs to issue a Certification Policy. We also decided to first address higher level objectives such as the need to support multiple CAs, self-governance, and/or Direct/Exchange support.

Goals
 * Need transparency
 * Need to enable self-governance
 * Need to allow for multiple trust anchors / vendors in the future
 * We are current addressing a number of this issues one at a time
 * May be more efficient to address these policy issues in a batch

Talking points
 * As we move towards self-governance this may help us
 * The current CP is vendor-controlled
 * The lack of a CP published by the NwHIN prevents transparency
 * The Direct Project has issued a minimal CP



Federal Bridge CP



**2011-11-18 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke (LM)
 * Andrew Weniger
 * Benson Chang (Deloitte)
 * Bob Hall
 * Cbaba
 * - Chuck Hagen (Deloitte)
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris (LM)
 * - Dave Arvin (SSA)
 * David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * James Rachin (ONC Test Team)
 * Jeff Tunkel
 * Joe Lamy (Nitor Group)
 * Joan DuHaime
 * John Donnelly
 * John Moehrke (GE)
 * - Josh Abraham (SSA)
 * Judith Hutman (Mitre Group)
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting (IBM)
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * Mike Levy (SSA)
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart (KP)
 * Sanjay
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Sourabh Pawar
 * Srinivasa Kukatla
 * - Shrikant Gajengi (SSA)
 * Seravina V
 * Steven Cason
 * Tom Davidson (SSA)
 * Wendy Laposata
 * - Eric Heflin (THSA)

Agenda:
 * Announcements
 * Issuer Tec/Policy guidance (issue #170)
 * Guidance for Tec/policy certificate revocation latency issues (issue #171)
 * Round table

Note: We had light attendance on the call today but were able to make progress on issues #170, and #171. Specifically, we finished the draft text for issue #170 and deemed it ready for email review by the Sec and Privacy WG. Same for issue #171 draft text. Eric presented CP-SP-001 (included as a linked document on this page, above) as the mechanism for addressing issue #170. No objections were raised to sending it to the Sec and Priv WG for a 1 week email review.


 * __Issue #170__**

We reviewed the CP-SP-001 in detail.


 * __Issue #171__**

Topic: x.509 Cert Revocation checking Goal: Create official guidance for the NwHIN Policy/Technical WG to consider and hopefully approve.

Background: Below are draft recommendations regarding cert revocation from this week's NwHIN Policy/Technical WG call.

X.509 Digital Certificate Revocation Policies


 * 1. Verification Frequency**

We will send the following text to the Sec and Priv WG for a 1 week review, and then the Spec Factory for a 1 month review prior to sending to the Policy/Technical Task Group.

Background for the NwHIN Policy/Technical Task Group: The process of validating a certificate is distinct from the process of checking for the revocation status of a certificate. The process of validating a certificate is an internal IT process that determines if a given certificate is within it's validity period, is issued under a trusted trust anchor, is signed properly, is intact, etc. The process of checking for the revoked status of a certificate involves using a trusted external source, such as CRL or and OCSP responder network to determine that a valid certificate has not be suspended or revoked. It is important to understand that a valid certificate can exist in revoked, suspended, or non-revoked status. Similarly a invalid certificate (such as one that has expired) will not be revoked in most cases. Thus is very important that implementors first check for the validity of a certificate before checking its revocation status. It is incorrect to check for the revocation status of a certification until that certificate's validity has been confirmed.

Recommendations:

a) Validation frequency checking: Implementations should check the validity of the reciprocal exchange partner's certificate each transaction.

b) Revocation frequency checking: Implementations should check the revocation status of the reciprocal exchange partner's certificate each transaction.

Issue: The messaging platform specification requires that either a CRL or OCSP be used to check whether a certificate is still valid. The specification does not address how often an Exchange Participant should verify whether a certificate has been revoked.

Recommendation: The messaging platform specification should be revised to reflect the following:

A Participant shall verify certificate validity each time a transaction is established.

Impact: This approach assures that participants verify certificate validity before exchanging data. The benefit of verifying certificate status outweighs potential performance issues.



**2011-11-14 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke (LM)
 * Andrew Weniger
 * Benson Chang (Deloitte)
 * Bob Hall
 * Cbaba
 * - Chuck Hagen (Deloitte)
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris (LM)
 * - Dave Arvin (SSA)
 * David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * James Rachin (ONC Test Team)
 * Jeff Tunkel
 * Joe Lamy (Nitor Group)
 * Joan DuHaime
 * John Donnelly
 * John Moehrke (GE)
 * - Josh Abraham (SSA)
 * Judith Hutman (Mitre Group)
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting (IBM)
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * Mike Levy (SSA)
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart (KP)
 * Sanjay
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Sourabh Pawar
 * Srinivasa Kukatla
 * - Shrikant Gajengi (SSA)
 * Seravina V
 * Steven Cason
 * Tom Davidson (SSA)
 * Wendy Laposata
 * - Eric Heflin (THSA)

Agenda:
 * Announcements
 * Deloitte help
 * Issuer Tec/Policy guidance (issue #170)
 * Guidance for Tec/policy certificate revocation latency issues (issue #171)
 * Round table

Note: We had light attendance on the call today but were able to make progress on issues #170, and #171. Specifically, we finished the draft text for issue #170 and deemed it ready for email review by the Sec and Privacy WG. Same for issue #171 draft text.


 * __Issue #170__**

Topic: SAML 

On today's call, we reviewed the below text and approved distributing it to the Sec and Priv WG. The Sec and Priv is to have one week to review and raise objections to the below text otherwise, it will be sent to the NwHIN Spec Factory "All Hands" mailing list to give them a 30 day opportunity to object. If no objections are received, then the below text will be submitted to the NwHIN Policy/Technical Task Group for consideration.

Goal: Need to create official statement from our WG for the NwHIN Policy/Technical to consider and hopefully approve. Result: Today we agreed approved the following two paragraphs for circulation to the NwHIN Spec Factory for feedback. We'll give the entire Spec Factory about 1 month to give them adequate time to review this policy with their respective organizations. Eric to write the below text into a Change Proposal form and send it to the Spec Factory.

Normative: The Nationwide Health Information Network Exchange uses the SAML 2.0  element as per the SAML 2.0 core specification, section 2.2.5 with the additional constraint that Nationwide Health Information Network Exchange participants MUST supply a string that uniquely indicates the name of the entity within the initiating gateway responsible for the on-going operations of the SAML 2.0 Authority.

Non-normative: The only known use, at this time, of the SAML  element by Nationwide Health Information Network Exchange participants is for audit logging. This element should indicate a group within the initiating gateway organization that operates the SAML Authority associated with each specific initiating gateway request. One approach used by some Nationwide Health Information Network Exchange participants is to supply a URI in the  element to uniquely identify the data center running the initiating gateway. If an organization supplies multiple initiating gateways for multiple clients within the vendor deployment, then the  string must indicate the specific client within the vendor-supplied environment. Thus the  string must, in this case, specify both the vendor hosting the gateway, and the client for which the gateway is being hosted.

[|DoD CP]


 * __Issue #171__**

Topic: x.509 Cert Revocation checking Goal: Create official guidance for the NwHIN Policy/Technical WG to consider and hopefully approve.

Background: Below are draft recommendations regarding cert revocation from this week's NwHIN Policy/Technical WG call.

X.509 Digital Certificate Revocation Policies


 * 1. Verification Frequency**

On today's call (2011-11-14). Background for the NwHIN Policy/Technical Task Group: The process of validating a certificate is distinct from the process of checking for the revocation status of a certificate. The process of validating a certificate is an internal IT process that determines if a given certificate is within it's validity period, is issued under a trusted trust anchor, is signed properly, is intact, etc. The process of checking for the revoked status of a certificate involves using a trusted external source, such as CRL or and OCSP responder network to determine that a valid certificate has not be suspended or revoked. It is important to understand that a valid certificate can exist in revoked, suspended, or non-revoked status. Similarly a invalid certificate (such as one that has expired) will not be revoked in most cases. Thus is very important that implementors first check for the validity of a certificate before checking its revocation status. It is incorrect to check for the revocation status of a certification until that certificate's validity has been confirmed.

Recommendations:

a) Validation frequency checking: Implementations should check the validity of the reciprocal exchange partner's certificate each transaction.

b) Revocation frequency checking: Implementations should check the revocation status of the reciprocal exchange partner's certificate each transaction.

Issue: The messaging platform specification requires that either a CRL or OCSP be used to check whether a certificate is still valid. The specification does not address how often an Exchange Participant should verify whether a certificate has been revoked.

Recommendation: The messaging platform specification should be revised to reflect the following:

A Participant shall verify certificate validity each time a transaction is established.

Impact: This approach assures that participants verify certificate validity before exchanging data. The benefit of verifying certificate status outweighs potential performance issues.

>> We reviewed the above approach and approved at the Security and Privacy Workgroup level. Next: we'll send this to the Spec Factory All Hands group to give them a chance to object.


 * 2. CA Revocation Update Latency**

Issue: ENTRUST processes revocations within 24-72 hours. By default, this has been accepted as the current working policy for Exchange. There is a desire to have a shorter response time to make revocations available within 1-2 hours.

Recommendation: The Exchange should revisit this policy as part of the planning process.

Impact: Faster updates to a CRL or OCSP assure that Participants know whether another Exchange participant is authorized to exchange. Faster turnaround times may result in higher costs for Exchange. This should be explored further.

>> What about multiple CAs? What is the impact? Ideally we'd like to see a latency of 1 hour. Perhaps point to the DoD CA latency? EJH to put link the DoD document, JL will research with Kevin P.


 * 3. Authority to Revoke Certificates (ejh note: Out of scope; presented for completeness and context only)**

Issue: The DURSA, as amended in May 2011 enables participants to voluntarily suspend or terminate their participation, including revocation of certificates. In addition, the amended DURSA enables the Coordinating Committee to suspend or terminate a participant’s participation in Exchange, including revocation of certificates.

The CC does not have the ability to technically issue / revoke certs, but directs a third party (in this case an ONC contractor) to do so.

The CC does not have formal legal authority to direct ONC or its contractors to issue / revoke certificates. ONC is voluntarily doing so in support of Exchange.

Recommendation: The Exchange should assure that the CC has formal authority to direct the issuance / revocation of certificates with the CA. This should be addressed as part of the planning and transition process.

Impact: There is some, although small, risk that the CC’s decisions would not be implemented.


 * __Issue #6__**



**2011-11-04 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke (LM)
 * Andrew Weniger
 * - Benson Chang (Deloitte)
 * Bob Hall
 * Cbaba
 * - Chuck Hagen (Deloitte)
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris (LM)
 * Dave Arvin (SSA)
 * David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * James Rachin (ONC Test Team)
 * Jeff Tunkel
 * Joe Lamy (Nitor Group)
 * Joan DuHaime
 * John Donnelly
 * John Moehrke (GE)
 * - Josh Abraham (SSA)
 * Judith Hutman (Mitre Group)
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting (IBM)
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * - Mike Levy (SSA)
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * - Sandy Stuart (KP)
 * Sanjay
 * Scott Robertson
 * - Seonho Kim
 * Sergei Haramundanis
 * Sourabh Pawar
 * Srinivasa Kukatla
 * - Shrikant Gajengi (SSA)
 * Seravina V
 * Steven Cason
 * - Tom Davidson (SSA)
 * Wendy Laposata
 * - Eric Heflin (THSA)

Agenda:
 * Announcements
 * Announcements
 * Deloitte help
 * TT blocking issues
 * RI Team blocking issues
 * Issuer Tec/Policy guidance (issue #170)
 * Guidance for Tec/policy certificate revocation latency issues (issue #171)
 * Working session on the ACP OID topic (issue #6)
 * Round table


 * __Issue #170__**

Topic: SAML  Goal: Need to create official statement from our WG for the NwHIN Policy/Technical to consider and hopefully approve. Result: Today we agreed approved the following two paragraphs for circulation to the NwHIN Spec Factory for feedback. We'll give the entire Spec Factory about 1 month to give them adequate time to review this policy with their respective organizations. Eric to write the below text into a Change Proposal form and send it to the Spec Factory.

Normative: The Nationwide Health Information Network Exchange uses the SAML 2.0  element as per the SAML 2.0 core specification, section 2.2.5 with the additional constraint that Nationwide Health Information Network Exchange participants MUST supply a string that uniquely indicates the name of the entity within the initiating gateway responsible for the on-going operations of the SAML 2.0 Authority.

Non-normative: The only known use, at this time, of the SAML  element by Nationwide Health Information Network Exchange participants is for audit logging. This element should indicate a group within the initiating gateway organization that operates the SAML Authority associated with each specific initiating gateway request. One approach used by some Nationwide Health Information Network Exchange participants is to supply a URI in the  element to uniquely identify the data center running the initiating gateway. If an organization supplies multiple initiating gateways for multiple clients within the vendor deployment, then the  string must indicate the specific client within the vendor-supplied environment. Thus the  string must, in this case, specify both the vendor hosting the gateway, and the client for which the gateway is being hosted.

[|DoD CP]


 * __Issue #171__**

Topic: x.509 Cert Revocation checking Goal: Create official guidance for the NwHIN Policy/Technical WG to consider and hopefully approve.

Background: Below are draft recommendations regarding cert revocation from this week's NwHIN Policy/Technical WG call.

X.509 Digital Certificate Revocation Policies


 * 1. Verification Frequency**

Issue: The messaging platform specification requires that either a CRL or OCSP be used to check whether a certificate is still valid. The specification does not address how often an Exchange Participant should verify whether a certificate has been revoked.

Recommendation: The messaging platform specification should be revised to reflect the following:

A Participant shall verify certificate validity each time a transaction is established.

Impact: This approach assures that participants verify certificate validity before exchanging data. The benefit of verifying certificate status outweighs potential performance issues.

>> We reviewed the above approach and approved at the Security and Privacy Workgroup level. Next: we'll send this to the Spec Factory All Hands group to give them a chance to object.


 * 2. CA Revocation Update Latency**

Issue: ENTRUST processes revocations within 24-72 hours. By default, this has been accepted as the current working policy for Exchange. There is a desire to have a shorter response time to make revocations available within 1-2 hours.

Recommendation: The Exchange should revisit this policy as part of the planning process.

Impact: Faster updates to a CRL or OCSP assure that Participants know whether another Exchange participant is authorized to exchange. Faster turnaround times may result in higher costs for Exchange. This should be explored further.

>> What about multiple CAs? What is the impact? Ideally we'd like to see a latency of 1 hour. Perhaps point to the DoD CA latency? EJH to put link the DoD document, JL will research with Kevin P.


 * 3. Authority to Revoke Certificates (ejh note: Out of scope; presented for completeness and context only)**

Issue: The DURSA, as amended in May 2011 enables participants to voluntarily suspend or terminate their participation, including revocation of certificates. In addition, the amended DURSA enables the Coordinating Committee to suspend or terminate a participant’s participation in Exchange, including revocation of certificates.

The CC does not have the ability to technically issue / revoke certs, but directs a third party (in this case an ONC contractor) to do so.

The CC does not have formal legal authority to direct ONC or its contractors to issue / revoke certificates. ONC is voluntarily doing so in support of Exchange.

Recommendation: The Exchange should assure that the CC has formal authority to direct the issuance / revocation of certificates with the CA. This should be addressed as part of the planning and transition process.

Impact: There is some, although small, risk that the CC’s decisions would not be implemented.


 * __Issue #6__**



**2011-10-28 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke (LM)
 * Andrew Weniger
 * - Benson Chang (Deloitte)
 * Bob Hall
 * Cbaba
 * Chuck Hagen (Deloitte)
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris (LM)
 * Dave Arvin (SSA)
 * David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * James Rachin (ONC Test Team)
 * Jeff Tunkel
 * - Joe Lamy (Nitor Group)
 * Joan DuHaime
 * John Donnelly
 * John Moehrke (GE)
 * Josh Abraham (SSA)
 * - Judith Hutman (Mitre Group)
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting (IBM)
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * Mike Levy (SSA)
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Sanjay
 * Scott Robertson
 * - Seonho Kim
 * Sergei Haramundanis
 * Sourabh Pawar
 * Srinivasa Kukatla
 * Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson (SSA)
 * Wendy Laposata
 * - Eric Heflin (Medicity)

Proposed Agenda:
 * Announcements
 * Proposed agenda:
 * Announcements
 * Changes for my role
 * Deloitte help
 * TT blocking issues
 * RI Team blocking issues
 * Issuer Tec/Policy guidance (issue #170)
 * Guidance for Tec/policy certificate revocation latency issues (issue #171)
 * Working session on the ACP OID topic (issue #6)
 * Round table


 * __Issue #170__**

Topic: SAML  Goal: Need to create official statement from our WG for the NwHIN Policy/Technical to consider and hopefully approve.

Normative: NwHIN Exchange use of the SAML 2.0  element uses the SAML 2.0 core specification, section 2.2.5, syntax and semantics. But NwHIN Exchange participants MUST supply a string that uniquely indicates the name of the entity within the initiating gateway responsible for the on-going operations of the SAML 2.0 security token service (STS).

Non-normative: This element should indicate a group within the initiating gateway that operates the STS associated with each specific initiating gateway request. One approach used by some NwHIN participants is to use a URI to the point to the data center running the initiating gateway. If an organization supplies multiple initiating gateways for multiple client within the vendor deployment, then the <Issuer> string must indicate the specific client within the vendor-supplied environment. Thus the <Issuer> string must, in this case, specify both the vendor and client.

Background: []

[]

Who is the issuer of the SAML assertion for NwHIN Exchange purposes? Currently the cert is an ONC-issued cert.


 * __Issue #171__**

Topic: x.509 Cert Revocation checking Goal: Create official guidance for the NwHIN Policy/Technical WG to consider and hopefully approve.

Background: Below are draft recommendations regarding cert revocation from this week's NwHIN Policy/Technical WG call.

X.509 Digital Certificate Revocation Policies


 * 1. Verification Frequency**

Issue: The messaging platform specification requires that either a CRL or OCSP be used to check whether a certificate is still valid. The specification does not address how often an Exchange Participant should verify whether a certificate has been revoked.

Recommendation: The messaging platform specification should be revised to reflect the following:

A Participant shall verify certificate validity each time a transaction is established.

Impact: This approach assures that participants verify certificate validity before exchanging data. The benefit of verifying certificate status outweighs potential performance issues.

>> We reviewed the above approach and approved at the Security and Privacy Workgroup level. Next: we'll send this to the Spec Factory All Hands group to give them a chance to object.


 * 2. CA Revocation Update Latency**

Issue: ENTRUST processes revocations within 24-72 hours. By default, this has been accepted as the current working policy for Exchange. There is a desire to have a shorter response time to make revocations available within 1-2 hours.

Recommendation: The Exchange should revisit this policy as part of the planning process.

Impact: Faster updates to a CRL or OCSP assure that Participants know whether another Exchange participant is authorized to exchange. Faster turnaround times may result in higher costs for Exchange. This should be explored further.

>> What about multiple CAs? What is the impact? Ideally we'd like to see a latency of 1 hour. Perhaps point to the DoD CA latency? EJH to put link the DoD document, JL will research with Kevin P.


 * 3. Authority to Revoke Certificates (ejh note: Out of scope; presented for completeness and context only)**

Issue: The DURSA, as amended in May 2011 enables participants to voluntarily suspend or terminate their participation, including revocation of certificates. In addition, the amended DURSA enables the Coordinating Committee to suspend or terminate a participant’s participation in Exchange, including revocation of certificates.

The CC does not have the ability to technically issue / revoke certs, but directs a third party (in this case an ONC contractor) to do so.

The CC does not have formal legal authority to direct ONC or its contractors to issue / revoke certificates. ONC is voluntarily doing so in support of Exchange.

Recommendation: The Exchange should assure that the CC has formal authority to direct the issuance / revocation of certificates with the CA. This should be addressed as part of the planning and transition process.

Impact: There is some, although small, risk that the CC’s decisions would not be implemented.


 * __Issue #6__**



**2011-10-21 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * - Ann Clarke (LM)
 * Andrew Weniger
 * - Benson Chang (Deloitte)
 * Bob Hall
 * Cbaba
 * - Chuck Hagen (Deloitte)
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris (LM)
 * - Dave Arvin (SSA)
 * David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * - James Rachin (ONC Test Team)
 * Jeff Tunkel
 * Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * - John Moehrke (GE)
 * Josh Abraham (SSA)
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * Mike Levy (SSA)
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Sanjay
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Sourabh Pawar
 * Srinivasa Kukatla
 * Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: Announcements Working session to create OASIS SAML 2.0 core spec changes Any new blocking RI Team issues Any new blocking T Team issues Roundtable





http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf

http://www.google.com/url?sa=t&rct=j&q=%25E2%2580%25A2%2509SAML%2B2.0%2BProfile%2BFor%2BXACML%2B2.0%2BOASIS%2BStandard%252C%2BSeptember%2B2011%2B&source=web&cd=1&ved=0CBsQFjAA&url=http%3A%2F%2Fwww.oasis-open.org%2Fcommittees%2Fdownload.php%2F43502%2Fxacml-profile-saml2.0-v2-spec-wd-15-en.odt&ei=ykahTrLHO8HfiALJkvRI&usg=AFQjCNGineqjUB-cA3xcVEBHnsys11snwg&sig2=aKT2e9Xqe-cV4XmtXYqLCQ

454 The fully-qualified value of the <saml:Attribute> DataType XML attribute MUST be used. If the <saml:Attribute> DataType XML attribute is missing, the XACML DataType XML attribute MUST be http://www.w3.org/2001/XMLSchema#string.

http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#muprocessing


 * 3.1 SOAP Features**

...

The specification of a feature MUST include the following:
 * __3.1.1 Requirements on Features__**
 * 1) A URI used to name the feature. This enables the feature to be unambiguously referenced in description languages or during negotiation.
 * 2) The information (state) required at each node to implement the feature.
 * 3) The processing required at each node in order to fulfill the obligations of the feature including any handling of communication failures that might occur in the underlying protocol (see also [|**4.2 Binding Framework**]).
 * 4) The information to be transmitted from node to node.

From Microsoft documentation: http://msdn.microsoft.com/en-us/library/77hkfhh8%28v=vs.71%29.aspx

<?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <MyHeader xmlns="http://www.contoso.com"> <Created>dateTime</Created> <Expires>long</Expires> </MyHeader> </soap:Header> <soap:Body> <MyWebMethod xmlns="http://www.contoso.com" /> </soap:Body> </soap:Envelope>

Discussion: Should we use SOAP headers instead of SAML attributes to convey certain information? It is possible (mechanically). But, an argument has been made that the current attributes are indeed intended to convey the transitory security context information. One can think of this as the conveyance of security context information more than direct end-user context information. It has been proposed that we move the policy OID attribute be moved to the 'root' SAML attribute and that we follow the IHE / OASIS work.

An BPPC-like consent document is in process at the ISO level as a non-normative spec pointing to HL7 CDA Consent Directive document. HL7 v2 has always had a consent flag (yes/no - consent was captured). A CDA template has been created that isa consent document type. Constrains BPPC with further attributes draft standard for trial use (DSTU). Indicates location of policy blob. Can leverage XACML / XSPA encoding.

Next steps: We decided on the call today that I'm to write-up a brief discussion about the two approaches (embedded assertion vs. pulling the policy OID attribute up higher) and send this to the S&P WG, and then the Spec Factory for consideration. Target is a vote in our WG by middle of November on the direction we'll take.



**2011-10-14 T-con**
No meeting 2011-10-14



**2011-10-06 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke
 * Andrew Weniger
 * - Benson Chang (Deloitte)
 * Bob Hall
 * Cbaba
 * - Chuck Hagen (Deloitte)
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris (LM)
 * - Dave Arvin (SSA)
 * David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * James Rachin
 * Jeff Tunkel
 * Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * - John Moehrke
 * - Josh Abraham (SSA)
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * Mike Levy (SSA)
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Sanjay
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Sourabh Pawar
 * Srinivasa Kukatla
 * Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: Announcements Working session to create OASIS SAML 2.0 core spec changes Any new blocking RI Team issues Any new blocking T Team issues Roundtable

Discussed moving the <saml2:Attribute Name="AccessConsentPolicy" NameFormat="http://www.hhs.gov/healthit/nhin"> <saml2:AttributeValue xmlns:ns6="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns7="http://www.w3.org/2001/XMLSchema" ns6:type="ns7:string">urn:oid:1.2.3.4</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="InstanceAccessConsentPolicy" NameFormat="http://www.hhs.gov/healthit/nhin"> <saml2:AttributeValue xmlns:ns6="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns7="http://www.w3.org/2001/XMLSchema" ns6:type="ns7:string">urn:oid:1.2.3.4.123456789</saml2:AttributeValue> </saml2:Attribute>

to the <saml2:Assertion xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="3a4edd62-458e-4c3f-adc0-a9b505cb6284" IssueInstant="2010-12-21T15:43:51.950Z" Version="2.0">

<saml2:AttributeStatement>

include component="backlinks" page="Security and Privacy Workgroup Meetings Q4 2011" limit="10"