Evaluation Criteria for Trust Anchors and Certification Authorities - IG Consensus
Jump to navigation Jump to search
Implementation Group Call for Consensus: Evaluation Criteria for Trust Anchors and Certification Authorities
(Yes or No)
|Comments (If "No," what can be changed to make it a "Yes")
|ABILITY (formerly VisionShare)
|American Academy of Family Physicians
|Clinical Groupware Collaborative
|We do not agree with the line: "Denial of prospective trust anchors must be based on these criteria and denials should be accompanied by the criterion violation that triggered the denial. Denial should not be based on subjective criteria, or on criteria not associated with protecting privacy, security and trust." Organizations may have other valid reasons to choose not to accept a particular trust anchor.
|Health-ISP, a service of Garden State Health Systems
|Greenway Medical Technologies
|High Pine Associates
|HLN Consulting, LLC
|Indiana State Department of Health
|Massachusetts eHealth Collaborative
|Medical Informatics Engineering, Inc./
|Medical University of SC, South Carolina Research Authority
|Misys Open Source Solutions (MOSS)
|NextGen Healthcare Information Systems, Inc.
|NYC Dept. of Health and Mental Hygiene’s PCIP
|Oregon HIE Planning Team
|Agree with EPIC and Siemens comments on wording for accepting trust anchor
|Rhode Island Quality Institute
|SCHIEx - South Carolina Health Information Exchange
|Secure Exchange Solutions
|Serendipity Health, LLC
|Wording suggestion: there may be some confusion engendered when the word "must" is used often, yet this is not a normative spec but a "best practices" document. Epic's comment seems affected by the "must be based" part of the sentence, whereas the last part of the sentence uses the word "should not be based on subjective criteria..." Nevertheless, substantively we can endorse this document.
|TN State HIE
|With a few notes - 1. It might be of value to share well served to discuss some of this with the FPKI PA at some level. 2. The concept of a RPS allows the delegation of Identity Proofing to the organization that is getting the certificates (a Trusted Agent). This makes it the participant responsible for identity proofing their employees and limits any liability that we as the CA has. And limit the audit requirements between parties. 3.EV SSL is not relevant beyond the EV SSL certificate and identifying the EE for certificates and that should be treated as separately.