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:
http://wiki.directproject.org/message/view/Direct+Ecosystem+Community+X.509+Certificate+Policy/42913426
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:
http://wiki.directproject.org/message/view/Direct+Ecosystem+Community+Consensus+Statement+-+August+4%2C+2011/41233991
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.