Direct Ecosystem Community Consensus Statement - August 4, 2011

Direct Ecosystem Community Consensus Statement

This interim consensus vote is a statement that the current contents of the Direct Ecosystem Community wiki page (version 0.1) and the Direct Ecosystem Community X.509 Certificate Policy are sufficient to make early progress possible. It is understood that issues of governance and Federal Ecosystem interoperability are not yet fully addressed.

V0.8 Consensus Votes (September 23, 2011)

Name	Organization	Endorsement (Yes, Yes with Comments, No)	Comments. If "No", what can be changed to make it yes?
Adrian Gropper	HealthURL	Yes
Andy Hereen	Cerner	Yes
Brian Ahier	Gorge Health Connect, Inc.	Yes
Brian Hoffman	DoD
Bruce Schreiber	MaxMD	Yes	1) I would like John Odden's concerns discussed and vetted. Is his conclusion that this CP will lead to two competing Trust systems correct? 2) 4.12 states:"This CP does not support key escrow and recovery." Is this meant to be a neutral comment or a negative comment? 3) This CP requires a DirectTrust.org entity. How will this be funded and brought to life?
Brett Peterson	ABILITY	Yes
Chris Moyer	MedPlus/Quest
Colin Barry
David Kibbe	AAFP	Yes
David McCallie	Cerner
Don Jorgenson	Inpriva	Yes, with comments	I think we can and should move quickly to get the governance structure in place. If it cannot happen soon, then we should adjust this CP so it can be referenced from within a Direct digital certificate.
Gary Christensen	RIQI	Yes
Greg Chittim	Arcadia/RIQI	Yes
Greg Meyer	Cerner	Yes
John Odden	Coto Partners	No	1/13/2012: At the time of the consensus call, the CP language was, in my recollection, agreed to be changed to read: "In any case where this CP found inconsistent or incompatible with the FBCA CP, the FBCA CP will govern" Instead, the Consensus edit was made DIFFERENTLY, as it appears on this Wiki: ".., incompatibilities will be addressed at the time of policy mapping." It appears that those who believe HHS should demand that Direct Project break from the FBCA CP and OMB M-11-11 have retroactively restored language that did not obtain Consensus. This issue is non-trivial. Many (vendor) participants and others sincerely believe that only Vendors should issue, manage and control IDENTITY on behalf of Providers and Patients. THIS small change in language is a "system integrity hole" that would FORCE Vendors and State Agencies (State Designated Entities) to create PLAIN TEXT POOLS of the health data of aggregated populations being served. Strict FBCA CP compliance is perhaps the ONLY PROTECTION that Providers and Patients have to assure their privacy and choice of disclosure of data, as they are assured by HIPAA. This one alteration of language is sufficient to drive the change from true HIPAA compliance to a model of 12 to 15 Vendors will control the nation's health data in PLAIN TEXT behind their firewalls. Does anyone believe that such an outcome is required, desired or within the scope of the industry to manage well? Let's either put back the promised language or recognize that this was NOT a Consensus. My sense is that activity seeking to fall under the Direct Project that is unable to tolerate FBCA CP compliance should be recognized as non-compliant and excluded, until such time as Providers and Patients can give informed consent to the approach of creating such massive clear text (plain text) data pools and placing their identities and their health care records solely into the hands of these third parties. This perspective is shared with a recognition that large, secure, clear text proprietary data pools do exist - behind Enterprise and Government Agency firewalls. It can be done. These "breach and hack targets" become compelling. Credit card breaches and loss of medical records from large health plans and hospitals make the headlines. THIS development would drive the creation of much larger, more compelling breach targets - Vendors that hold all of our Identities AND Health Records in clear text. And that is why we keep seeing language about "health care / the Direct Project cannot comply with FBCA CP." It can't comply if we are going to give up on keeping our data compartmentalized and private and instead create the largest clear text health data pools ever conceived. That's why the FBCA CP is written as it is. And why the notion that "we must break FBCA CP for health care" deserves more attention and a full, transparent debate. Such a consensus may emerge in the future. To me, this group is not the right level and breadth of stakeholders to take such an action - especially not after the Consensus was called and agreed. Which do we want? My Yes vote was expressed as 100% reliant on FULL FBCA CP COMPLIANCE, not on pushing an ill-conceived effort to break OMB M-11-11 forward into 2012. We should never break OMB M-11-11 - that makes no sense at all. =* * *==<below comments come from prior to the Consensus Call and stand>= Colleagues: Thank you for addressing: (a) Please remove "with respect to verification and validation {of} identity" from Sec. 1. (b) Since it is "understood that issues of governance ... are not yet fully addressed" please edit the language so that this CP is operable today under RoTR and does not need to "wait for DirectTrust.org" to be meaningful You'll find added discussion here: [1]
John Williams	Health-ISP
Mark Gingrich	Surescripts
Mark Stine	MedPlus/Quest
McLain Causey	ABILITY Network Inc
Noam Arzt	HLN
Pat Pyette	Inpriva
Pete Palmer	Surescripts
Sean Nolan	Microsoft
Sri Koka	Techsant	Yes
Steve Waldren	AAFP
Umesh Madan	Microsoft
Vince Lewis
Will Ross	Redwood MedNet		.

V0.5 Consensus Votes (August 15, 2011)

Name	Organization	Endorsement (Yes, Yes with Comments, No)	Comments. If "No", what can be changed to make it yes?
Adrian Gropper	HealthURL	Yes with Comments	The Approved Application restriction (4.5.1) is vague and possibly misguided. The organizational policies around application approval seem to be beyond the scope of DirectTrust.org. If this restriction is required for technical or FBCA compatibility reasons then accept my apologies for wasting your time. Otherwise, please explain where this fits in.
Andy Hereen	Cerner	Yes
Brian Ahier	Mid-Columbia Medical Center	Yes with Comments	This policy must be maintained so it is consistent with the FBCA CP
Brian Hoffman	DoD	Yes
Bruce Schreiber	MaxMD	Yes, with comments	The success of this structure depends on counter party certificate discovery and private key management. My concerns are: - Private Key concerns: If the hisp manages the private key, how strong and consistent is the individual authentication. Alternatively, can a user or provider properly guard and maintain a private key on an individual level? - Certificate Discovery concerns BIND as offered in CPANEL, or the Rackspace Portal or Godaddy Portal do not support CERT records at this time. Is there an alternative TXT record format that can be acceptable? There has been talk of using SRV records pointing at LDAP servers. That could be included here as well as a reference to an LDAP implementation standard. When is the domain only cert acceptable versus the individual cert? Is that a responsibility of the sender or is there a policy?
Brett Peterson	ABILITY	Yes
Chris Moyer	MedPlus/Quest	Yes
Colin Barry
David Kibbe	AAFP	Yes
David McCallie	Cerner	Yes
Don Jorgenson	Inpriva	Yes, with comments	Concerns/questions: - The Direct Ecosystem CP seems to anticipate a DirectTrust.org CA compliance process that largely duplicates that required by the FBCA. Why not include FBCA requirements by reference and focus on the Direct specific requirements? If FBCA compliance becomes a requirement, the Direct Ecosystem CP could be specified and maintained by DirectTrust.org without the necessity of establishing a separate enforcement infrastructure. FBCA required audits could be extended to cover Direct Ecosystem CP compliance. - There remain material inconsistencies to be worked out between the Direct Ecosystem Community wiki page, the Direct Ecosystem CP, requirements of the “Applicability Statement for Secure Health Transport” and requirements of the FBCA CP--some of these impact certificate content and interoperability. - In the FBCA CP, CAs designate their own RAs and are responsible for their compliance with the CP—why not follow that model? (Sect. 1) - Should DNS publication be the responsibility of the CA or the HISP? (Sect. 2.3) - Subscribers should not be required to “…utilize their Direct Ecosystem certificate only with applications approved for use by DirectTrust.org.” (Sect. 4.5.1)
Gary Christensen	RIQI	Yes with comments	Yes vote assumes that the approval is as stated above, that this is a document that is a good start and should move forward. There is still some more work to do to align the CP with the FBCA, in particular:* Section 3.2.3.1 requires that a public notary verify identity documents - this should be updated to allow a notary or the RA to physically verify identity documents Section 8 DirectTrust.org duties - share the same concerns as Don Jorgenson above
Greg Chittim	Arcadia/RIQI	Yes with comments	See Gary Christensen and Don Jorgenson's comments above
Greg Meyer	Cerner	Yes
John Odden	Coto Partners	Yes with comments	This "Yes" vote is contingent on this CP explicitly inserted specific language in the appropriate section (suggesting as new paragraph at the end of Section 1) that "This CP is restricted to fully comply with the current FBCA and shall not be construed to interfere with the cross certification of PKIs under the FBCA, particularly with respect to 'org id cert policy.' In any case of non-compliance or interference, the current FBCA and cross certified PKIs, policies, and practices will have precedence over this CP." This type of language should clarify that Direct Project requirements are within OMB 11-11 and will not disrupt established 'ord id cert policies' that already work well and are deemed fully compliant under the FBCA. Yet it will also be "forward compatible" with any helpful refinements from HITSC, GSA, NIST, ONC, the Congress or any others who support acceleration of Direct Project success. Personally I would greatly prefer that we appropriate recommend the formation and role of DirectTrust.org as a highly beneficial actor in the refinement and expansion of Direct Project success. A bit more background may be found here: [2]
John Williams	Health-ISP	Yes
Mark Gingrich	Surescripts	Yes with comments	This “Yes” vote is contingent on this CP not interfering with FICAM policies and/or the Kantara’s IAF that will comply with Tiger Team recommendations associated with the Direct Federal Community. We expect FICAM will address organization identity CP in near term.
Mark Stine	MedPlus/Quest
McLain Causey	ABILITY Network Inc	Yes
Noam Arzt	HLN
Pat Pyette	Inpriva
Pete Palmer	Surescripts
Sean Nolan	Microsoft	Yes with comments	Before the "RoTR" are really usable --- we will need a complementary set of policies for HISPs ... but this is an excellent CP for the community to move forward wrt Certificate Authorities.
Sri Koka	Techsant	Yes
Steve Waldren	AAFP	Yes
Umesh Madan	Microsoft
Vince Lewis
Will Ross	Redwood MedNet	yes with comments	This yes vote is for the CP conceptually while expressing two concerns: 3.2.3.1 as written lacks clarity on the imposition of a notary in the directtrust.org (or equivalent) identity proofing process; and 3.1.2 may have unintended consequences at scale as naming conventions collide and evolve.